Christian Schafmeister
2015-Feb-16 19:47 UTC
[LLVMdev] What is on the LLVM horizon for truly relocatable JITted code?
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
David Blaikie
2015-Feb-16 20:06 UTC
[LLVMdev] What is on the LLVM horizon for truly relocatable JITted code?
+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/f3064d9c/attachment.html>
Lang Hames
2015-Feb-16 20:46 UTC
[LLVMdev] What is on the LLVM horizon for truly relocatable JITted code?
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>
Christian Schafmeister
2015-Feb-16 21:00 UTC
[LLVMdev] What is on the LLVM horizon for truly relocatable JITted code?
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>
David Chisnall
2015-Feb-16 21:47 UTC
[LLVMdev] What is on the LLVM horizon for truly relocatable JITted code?
On 16 Feb 2015, at 19:47, Christian Schafmeister <chris.schaf at verizon.net> wrote:> > 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?I'm not sure what this actually buys you. There are a few reasons why you don't want to treat code compiled and data in the same way: - You want code to be executable but not writeable - Code doesn't typically support the infant mortality hypothesis (things in eval and so on can be special-cased in a short-lived allocation, the source cached, and recompiled if they persist more efficiently than trying to move code around) - Code can't be scanned for roots in the same way as data as immediate pointer values may be materialised across multiple instructions (not important if your code only ever refers to globals via arguments). - The set of reachable objects from a piece of compiled code never changes over its entire lifetime. - You should never have to deal with interior pointers to code, except return addresses on the stack. For this reason, most modern systems that do run-time code generation have one or more special regions for code, often with copies of the pointers stored alongside. There's nothing stopping you from relocating a closure object that refers to a function with your data GC and using the deallocation event to trigger the RTDyldMemoryManager to be allowed to recycle the memory. As the existing infrastructure permits you to relocate code to its final position after initial code generation, you can pick a suitable size from your free list. David
Bruce Hoult
2015-Feb-16 22:48 UTC
[LLVMdev] What is on the LLVM horizon for truly relocatable JITted code?
On Tue, Feb 17, 2015 at 8:47 AM, Christian Schafmeister < chris.schaf at verizon.net> wrote:> 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? >Will you be able to find and patch return addresses on the stack? Or, as the stack is only conservatively scanned, the presence of a possible pointer into the code prevents it being moved? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150217/b4243c6f/attachment.html>