[LLVMdev] GC questions.
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
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).
More information about the llvm-dev