[LLVMdev] What is on the LLVM horizon for truly relocatable JITted code?

[Christian Schafmeister]

Lang,

Thank you!

That is a very interesting idea to cache a relocatable version of the code to move it wherever the GC wants it to go and then discard it once the GC determines that it is no longer referenced  I’ll have to ponder this idea.  I think I could implement that with what I have right now.  I don’t expect code to move around too much - most will end up in the oldest generation and then stay put.  I’ll have to talk to the folks at Ravenbrook (who wrote the MPS garbage collector) to see if I can relocate the code rather than let the MPS library move the code.

Thanks again.

Best,

.Chris.


On Feb 16, 2015, at 3:46 PM, Lang Hames <lhames at gmail.com> wrote:

> Hi Christian,
> 
> At the moment we support PIC in the sense that you can, through the RTDyldMemoryManager, map text/data sections wherever you like. Once they've been laid down however, the current JIT infrastructure treats them as fixed. It sounds like you want to go further than that and slide text/data around during garbage collection? You might be able to do that with the current infrastructure by holding on to the relocatable objects and re-emitting text sections to new locations as needed (the data sections you would have to move manually so as not to overwrite away any changes). Unfortunately this would double your memory overhead since you would have two copies of all your sections: The emitted version and the cached, relocatable version. With a bit of work you could teach the JIT linker (RuntimeDyld) to optionally hold on to the necessary relocations and so eliminate that overhead too.
> 
> So, I don't think you can do this today, but with a bit of effort I think it could be made to work. It certainly sounds like an interesting idea.
> 
> Cheers,
> Lang.
> 
> 
> On Mon, Feb 16, 2015 at 12:20 PM, Christian Schafmeister <chris.schaf at verizon.net> wrote:
> 
> David,
> 
> Well, thank you very much!   I’ll be very interested to talk with Lang.  I CC’d him on this email.
> I have a fully functional Common Lisp compiler that uses the LLVM C++ API extensively and does all sorts of weird and wonderful things with it.
> 
> My use-case of the LLVM-JIT code may be one of the furthest “out-there” of any compiler so far.
> 
> 
> Best,
> 
> .Chris.
> 
> 
> On Feb 16, 2015, at 3:14 PM, David Blaikie <dblaikie at gmail.com> wrote:
> 
>> I was just cc'ing Lang Hames, one of the LLVM developers, onto this thread to bring it to his attention.
>> 
>> He's taken ownership of the JIT recently and has been experimenting with a new JIT API (called ORC) that is designed to be a composable system providing infrastructure for a variety of JIT use cases. I don't know that he's considered the use case you have, but I'm sure he'll be glad to give it some thought.
>> 
>> On Mon, Feb 16, 2015 at 12:12 PM, Christian Schafmeister <chris.schaf at verizon.net> wrote:
>> David,
>> 
>> What’s +Lang?    I googled “llvm +Lang” and found a few random posts but nothing concrete.
>> Is it the final resting place of strange JIT requirements/requests?
>> 
>> Best,
>> 
>> .Chris.
>> 
>> 
>> 
>> On Feb 16, 2015, at 3:06 PM, David Blaikie <dblaikie at gmail.com> wrote:
>> 
>>> +Lang, collector of strange JIT requirements
>>> 
>>> On Mon, Feb 16, 2015 at 11:47 AM, Christian Schafmeister <chris.schaf at verizon.net> wrote:
>>> 
>>> Hello everyone,
>>> 
>>> 
>>> Is fully relocatable/position-independent JITted code on the horizon or currently possible with LLVM?
>>> 
>>> I’ve written a Common Lisp compiler (currently called Clasp:  https://github.com/drmeister/clasp) in C++ that uses LLVM as the backend and interoperates with C++.  It uses copying garbage collection via the Memory Pool System (MPS) garbage collector by Ravenbrook.  This garbage collector is precise on the heap and conservative on the stack.
>>> 
>>> Currently I JIT code to wherever LLVM drops the code and it remains fixed in memory.  This causes some problems for implementing a dynamic language like Common Lisp because CL considers data and code to be equivalent.
>>> 
>>> I’d like to move the code into the MPS managed memory and be able to apply copying garbage collection to it.  Is this possible?   Will it ever be possible?
>>> 
>>> Best,
>>> 
>>> Christian Schafmeister
>>> Professor
>>> Chemistry Department
>>> Temple University
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>> 
>> 
>> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150216/3a2223de/attachment.html>