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

[Tony Hosking]

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!