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

[Lang Hames]

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/f4b97e02/attachment.html>