[M3devel] returning record by value vs. by ref?

[Tony Hosking]

If this really interests you then you might read this paper: http:// 
doi.acm.org/10.1145/143095.143140 .

On Dec 1, 2007, at 5:36 PM, Jay wrote:

> > 2, don't understand
>
> You said it'd take much cooperation with the compiler, due its  
> optimizations, but optimizations can be defeated as necessary.
> Interior pointers could be marked, perhaps, volatile, so prevent  
> enregistration. I can see that's a potentially high cost though.
>
> like
> Record_t *Record = GetRecord();
> unsigned i;
> for (i = 0 ; i != Record->j ; ++i)
> {
>   ...
> }
>
> You'd really like Record->j to not be refetched for every loop  
> iteration, but if Record is volatile so the GC can move what it  
> points to and update outstanding pointers, you'd be stuck with  
> something like that. Besides, if j can't be read in one  
> instruction, more problems, assuming a concurrent GC, that cannot  
> reliably get/set the context of other threads. I think, like, you  
> could reliably get/set context on a uniprocessor system, but not a  
> multiprocessor. You'd have to suspend, wait for the suspend to  
> happen.. I guess that could work, but it seems like you'd want to  
> avoid designs that require suspending threads. ?
> Hm. No, it's difficult. This being a short lived pointer, gc  
> happening on another thread, you'd have to, like, "register" its  
> location with the gc.
>
> Hm. Just how does it work?
>
> gc suspends threads and updates variables? I don't think so.
>
> Variables that are moved leave some sort of "forwarding address"  
> for holders of the old value?
>
> The gc isn't concurrent but is called at function entry/exit? I  
> don't think so.
>
> I should check the docs and code..
>
>  - Jay
>
>
>
> > From: hosking at cs.purdue.edu
> > Date: Sat, 1 Dec 2007 17:19:46 -0500
> > To: jay.krell at cornell.edu
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] returning record by value vs. by ref?
> >
> >
> > On Dec 1, 2007, at 5:14 PM, Jay wrote:
> >
> > > 1) Can pinning not be exposed reasonably in the language?
> > > I'll keep my pointer just a short time, in a local.
> >
> > Yes, that is a *hack* that will work only with the current
> > conservative garbage collector. In general, the compiler might
> > record that the local is a pointer derived from some base reference
> > and if the GC decides to move the base object it can adjust the  
> local
> > derived pointer accordingly.
> >
> > > 2) surely it could be done at an outer layer?
> > > Make volatile locals for things you don't want enregistered?
> >
> > I don't understand what you mean by this.
> >
> > > Even the accessor function approach seems lame, given that I
> > > believe the Win32/x86 compiler doesn't inline.. :(
> > > (does the gcc m3 inline across modules, or just compiles one at a
> > > time?)
> >
> > gcc m3 inlines only within compilation units.
> >
> > >
> > >
> > > - Jay
> > >
> > >
> > > > CC: jay.krell at cornell.edu; m3devel at elegosoft.com
> > > > From: hosking at cs.purdue.edu
> > > > Subject: Re: [M3devel] returning record by value vs. by ref?
> > > > Date: Sat, 1 Dec 2007 15:23:19 -0500
> > > > To: rodney.bates at wichita.edu
> > > >
> > > > Correct! Anytime you create an l-value pointer.
> > > >
> > > > On Dec 1, 2007, at 2:31 PM, Rodney M. Bates wrote:
> > > >
> > > > > Tony Hosking wrote:
> > > > >> I am assuming 's' here is an open array (REF ARRAY OF  
> item) in
> > > > >> which case it is allocated in the GC'd heap. There is  
> certainly
> > > > >> no way of safely getting an interior pointer to items in the
> > > > >> stack in Modula-3 -- at least not one that you can upward  
> expose
> > > > >> (to callers) via return from a procedure. The difficulty in
> > > > >> doing this is that the GC moves objects around and would  
> need to
> > > > >> know where your manufactured interior pointer is being  
> held and
> > > > >> to which *object* (ie, the open array in this case) it  
> refers so
> > > > >> that it can 'fix' the pointer when the array object moves.
> > > > >> Modula-3 provides a small concession to obtaining downward
> > > > >> exposed interior pointers using the VAR parameter mode. For
> > > > >> example you can pass 's[i]' as an actual parameter to a  
> VAR mode
> > > > >> formal, effectively passing a pointer to the callee. GC  
> can cope
> > > > >> with this in one of two possible ways: 1) "Pin" the array  
> so that
> > > > >> it cannot be moved while the interior pointer is held on the
> > > > >> stack or registers of any thread (this is the approach  
> that CM3's
> > > > >> conservative collector uses for now); or 2) track the  
> creation of
> > > > >> such interior pointers and how they are derived from base  
> object
> > > > >> references for use during GC. 2) requires much more co- 
> operation
> > > > >> from the compiler than the current gcc-based backend (with  
> all of
> > > > >> its lovely optimizations and register allocation) is  
> capable of
> > > > >> doing. 1) is very cheap and does not impede optimizations and
> > > > >> register allocation.
> > > > >
> > > > > Presumably, this all also applies WITH-bound identifiers, when
> > > they
> > > > > are
> > > > > designators of interior components of heap objects? Are  
> there any
> > > > > other
> > > > > cases?
> > > > >
> > > > > --
> > > > > -------------------------------------------------------------
> > > > > Rodney M. Bates, retired assistant professor
> > > > > Dept. of Computer Science, Wichita State University
> > > > > Wichita, KS 67260-0083
> > > > > 316-978-3922
> > > > > rodney.bates at wichita.edu
> > > >
> > >
> > >
> > > Your smile counts. The more smiles you share, the more we donate.
> > > Join in!
> >
>
>
> Get the power of Windows + Web with the new Windows Live. Power up!