[LLVMdev] Interfacing llvm with a precise, relocating GC

Philip Reames listmail at philipreames.com
Fri Oct 25 11:50:44 PDT 2013


On 10/24/13 2:50 PM, Rafael EspĂ­ndola wrote:
> On 24 October 2013 17:32, Sanjoy Das <sanjoy at azulsystems.com> wrote:
>> Hello llvm-dev!
>>
>> My colleages and I are currently evaluating llvm's suitability as a
>> JIT compiler interfacing with a precise, relocating garbage collector.
>> While we couldn't find code or writeups that deal with the issues
>> specific to this design goal, it is entirely possible that we may have
>> missed something; we would appreciate references to relevant code or
>> writeups that people on this list may be aware of.
>
> This would be hard. Currently what we have support for is a non-moving
> GC where all the roots are in memory. Adding support for a non-moving
> gc with register roots would not be too hard and might be possible to
> reuse some of the recent stackmap work.
Agreed,  I think all the mechanisms are either in tree already, or 
shortly to be so.  There's still a fair amount of work required to make 
it all work together, but the task seems approachable.
> For a moving GC you would probably have to change how we represent
> pointer arithmetic in the selection dag and MI. It would be quiet a
> big change. CCIng Andy and Patrick since they might have an idea of
> how much work that would be and what the costs and benefits for LLVM
> are.
>
> Also to note is that there are plans to move away from selection dag,
> so it might be good to sync this work with whatever we end up using
> instead.
Ouch.  I hadn't realized that GEPs were desugared to integer arithmetic 
that early. That does seem like it would be a problem. Thank you for 
pointing this out.

Assuming we had a scheme to avoid/solve this specific issue, are you 
aware of any other ones?

Can you point me to any previous discussion of the selection dag 
migration?  This isn't a topic I usually follow on the list.  A quick 
search didn't find the conversations you're referencing.

Philip




More information about the llvm-dev mailing list