llvm dev - Jul 2004 - [LLVMdev] GC questions.

On Mon, 19 Jul 2004, Tobias Nurmiranta wrote:
> > Not currently.  In the future this will definitely be improved.  In
> > particular, when the code generators are enhanced to provide more
accurate
> > mapping information for GC pointers (e.g. which registers contain
> > pointers), we can do this.  This is in the long term plans, but I
suspect
> > that performance will be fine without it for many applications.
>
> How are pointers to heap-data in registers handled right now? Or am I only
> allowed to use pointers indirectly through the stack?
Unfortunately we don't have any front-ends using the GC currently (though
several are in progress of being developed).  The idea is to have a
call-back, provided by the front-end, which provides pointer mapping
information.

In the Java-style world, this hook would look at the type-information
hanging off of the object vtable to know where the pointers are in the
object.  In a scheme world, this hook could look at the elements directly
and "know" whether they are pointers (based on bit-patterns).
> > llvm.gcroot is an abstraction.  Your front-end is telling the code
> > generator and optimizer what locations can be modified unpredictably
at
> > runtime by the GC system.   Right now we do not have many clients of
the
> > gc interfaces, so they do not produce wonderful code, but this will
change
> > in time.  :)
>
> Ok, I guess it in the future would be nice if the llvm.gcroot abstraction
> could be applied to SSA-variables as well as the stack, and then
> transformed by the compiler.
Yes, it will be.
> Is the code available for any of these clients?
llvm-java is in public CVS, but it is not GC enabled.  Unfortunately, the
GC implementation is not 100% complete, but it does give you all of the
information you need from the code generator (the ability to identify and
modify roots on the stack).

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://nondot.org/sabre/

Hi, I'm thinking out loud, please give me some feedback.

Regarding llvm.gcread and llvm.gcwrite, wouldn't it be nicer if they are
implemented as:

 llvm.gcread(sbyte** object, uint offset)
 llvm.gcwrite(sbyte* data, sbyte** object, uint offset)

Where you also have the offset into the object. In this way the GC would
know where the header of the object we are reading/writing to is. Also it
would mean less traffic to the pointers on the stack, and in some
languages you only want to allow pointers to the header of the objects,
which makes object traversal easier.

Btw, could you give some hints on where the GC functionality is
handled in the source tree (llvm.gcroot, gcread, gcwrite).

,	Tobias

On Wed, 21 Jul 2004, Tobias Nurmiranta wrote:
>
> Btw, could you give some hints on where the GC functionality is
> handled in the source tree (llvm.gcroot, gcread, gcwrite).
Disregard this question, found it :).

On Wed, 21 Jul 2004, Tobias Nurmiranta wrote:
>
> Hi, I'm thinking out loud, please give me some feedback.
>
> Regarding llvm.gcread and llvm.gcwrite, wouldn't it be nicer if they
are
> implemented as:
>
>  llvm.gcread(sbyte** object, uint offset)
>  llvm.gcwrite(sbyte* data, sbyte** object, uint offset)
>
> Where you also have the offset into the object. In this way the GC would
> know where the header of the object we are reading/writing to is. Also it
> would mean less traffic to the pointers on the stack, and in some
> languages you only want to allow pointers to the header of the objects,
> which makes object traversal easier.
Yes, this makes a tremendous amount of sense.  Do you think you could
prepare some patches to make this happen?  If you have any questions, feel
free to ask :)

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://nondot.org/sabre/