[LLVMdev] GC questions.

Chris Lattner sabre at nondot.org
Mon Jul 19 16:24:47 PDT 2004


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/




More information about the llvm-dev mailing list