[LLVMdev] llvm.gcroot suggestion

[Joshua Warner]

Hi Talin,

Sorry to interject -


> For example, suppose I have a type "String or (float, float, float)" - that
> is, a union of a string and a 3-tuple of floats. Most of the time what LLVM
> will see is { i1; { float; float; float; } } because that's bigger than {
> i1; String* }. LLVM won't even know there's a pointer in there, except
> during those brief times when I'm accessing the pointer field. So tagging
> the pointer in a different address space won't help at all here.
>
>
I think this is a fairly uncommon use case that will be tricky to deal with
no matter what method is used to track GC roots.  That said, why not do
something like make the pointer representation (the {i1, String*}) the
long-term storage format, and only bitcast *just* before loading the
floats?  You could even use another address space to indicate that something
is *sometimes* a pointer, dependent upon some other value (the i1, perhaps
indicated with metadata).

My vote (not that it really counts for much) would be the address-space
method.  It seems much more elegant.

The only thing that I think would be unusually difficult for the
address-space method to handle would be alternative pointer representations,
such as those used in the latest version of Hotspot (see
http://wikis.sun.com/display/HotSpotInternals/CompressedOops).  Essentially,
a 64-bit pointer is packed into 32-bits by assuming 8-byte alignment and
restricting the heap size to 32GB.  I've seen similar object-reference
bitfields used in game engines.  In this case, there is no "pointer" to
attach the address space to.

(Yes, I know that Hotspot currently uses CompressedOops ONLY in the heap,
decompressing them when stored in locals, but it is not inconceivable to
avoid decompressing them if the code is just moving them around, as an
optimization.)

Just my few thoughts.

-Joshua
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110307/868992ab/attachment.html>