[LLVMdev] MCJIT and Lazy Compilation

[Andrew Sorensen]

OK, so I have some *preliminary* results, which are on the whole quite
encouraging!

I haven't had a great deal of time, but I have managed to get Extempore up
and
running with function (actually lexical closures so composed of quite a bit
of additional
guff) level compilation using Andy's multi module suggestion. I also have
on-the-fly
recompilation of existing closures working (caveats below) so from an
end-user
perspective this means that Extempore appears functionally equivalent with
MCJIT
and the old legacy JIT - hot-swapping audio signal processing code
on-the-fly using
MCJIT for example.

Firstly multi-module definitely proved to be considerably easier than
attempting to hack
solutions for incremental *monolithic* module builds - which I also
investigated.

So the only major obstacle that I have run into so far are page permissions
in relation
to code relocations.  I have a *safe* hack which is to toggle section
permissions between
rw and exec/ro in-between new object injections - however this is obviously
problematic
for code that is executing concurrently (i.e. secondary threads).  I also
have an *unsafe*
hack, (purely for experimentation :-) whereby exec sections are left rw,
and although
very evil it works for test purposes (i.e. the audio example mentioned
above).  These
solutions are obviously both inappropriate and I will investigate a *real*
solution when
I find some time.

Also I didn't bother to implement section erasure, at the moment I'm just
allocating
new sections for each compile regardless of whether the new code replaces
existing
functionality. Having said that I don't see this as much of an issue, I was
just to
lazy to bother implementing it.  I'll check this when I have some further
free time.

FYI this is all under x86.  I did try to run under ARM but bombed out on an
assertion error
in the ARM ELF relocation code - specifically   assert((*TargetPtr &
0x000F0FFF) == 0);
I assume this is a result of something evil that I have done but I haven't
yet had time to
investigate any further.  Again I'll let you know when I have some more
time.

Just a quick heads up but In general my initial thoughts are that MCJIT is
really not
that far off.

Cheers,
Andrew.











On Fri, Feb 8, 2013 at 7:36 AM, Kaylor, Andrew <andrew.kaylor at intel.com>wrote:

>  That’s awesome!****
>
> ** **
>
> I think at this point having people try out various approaches and seeing
> what works and what doesn’t is our biggest need in this area.  Please do
> keep me informed about what you find out.****
>
> ** **
>
> -Andy****
>
> ** **
>
> *From:* Andrew Sorensen [mailto:digegoo at gmail.com]
> *Sent:* Wednesday, February 06, 2013 4:33 PM
> *To:* Kaylor, Andrew
> *Cc:* llvmdev at cs.uiuc.edu
> *Subject:* Re: [LLVMdev] MCJIT and Lazy Compilation****
>
> ** **
>
> Thanks for the update Andy.****
>
> ** **
>
> I'm very happy to be involved in anyway that is helpful.  If you would
> like me to test ideas, or contribute to further discussions, then please
> let me know.****
>
> ** **
>
> I currently have extempore running nicely with MCJIT for the "monolithic"
> case and am working on various LLVM hacks to better understand the issues
> involved with non-monolithic approaches - in particular I'm starting with
> your multi-module approach.  I will report back when (and if) I have
> something useful to contribute.****
>
> ** **
>
> Cheers,****
>
> Andrew.****
>
> ** **
>
> On Wed, Feb 6, 2013 at 4:08 AM, Kaylor, Andrew <andrew.kaylor at intel.com>
> wrote:****
>
> Hi Andrew,****
>
>  ****
>
> I was about to write a belated reply to this message (sorry for the
> delay), but then I realized that pretty much everything useful that I have
> to say on the subject is contained in this message (which is in a thread
> Albert Graef already linked to):****
>
>  ****
>
> https://groups.google.com/d/msg/llvm-dev/Rk9cWdRX0Wg/Fa1Mn6cyS9UJ****
>
>  ****
>
> Generally, I do hope that MCJIT will be capable of replacing the old JIT
> someday soon, though obviously it cannot do so until it provides equivalent
> functionality.  I doubt it will ever be a “drop-in” replacement, but I hope
> that minimal rework will be needed.  Most significantly, as can be seen in
> earlier discussions, things will need to be made Module-centric rather than
> Function-centric.  It ought to be possible to write a utility class that
> takes a monolithic Module and breaks it up into sub-Modules for individual
> functions, but I think that would need to happen outside of the MCJIT
> engine because not all clients would want that kind of granularity.****
>
>  ****
>
> There’s definitely a lot of work to be done here to get this right, and
> hopefully we’ll get active participation in any design discussions to make
> sure the solution meets everyone’s needs.  I don’t have a time table for
> this right now.  I will file a Bugzilla report as soon as the LLVM server
> is ready.****
>
>  ****
>
> -Andy****
>
>  ****
>
> *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] *On
> Behalf Of *Andrew Sorensen
> *Sent:* Thursday, January 31, 2013 7:56 PM
> *To:* llvmdev at cs.uiuc.edu
> *Subject:* [LLVMdev] MCJIT and Lazy Compilation****
>
>  ****
>
> Does anyone have a roadmap for MCJIT with what I think people are ****
>
> calling lazy compilation.****
>
>  ****
>
> Is this even on the cards?****
>
>  ****
>
> I spent the last few hours moving my project (extempore.moso.com.au) ****
>
> over to MCJIT (particularly for ARM), and am a little horrified to
> discover ****
>
> no ability to compile, and just as importantly to recompile, at a function
> level.  ****
>
> This is absolutely mandatory for my project.  ****
>
>  ****
>
> I have been looking enviously at MCJIT's ARM+DWARF support for a ****
>
> couple of years and was under the misapprehension that MCJIT was ****
>
> attempting to be a *drop-in* replacement for JIT.  So I wasn't overly****
>
> concerned about the primary JIT being largely neglected. This is obviously
> ****
>
> my fault, I wasn't paying close enough attention.****
>
>  ****
>
> I am now wondering what the LLVM project, in the large, plans regarding **
> **
>
> just-in-time compilation moving forward.  Is MCJIT the future, and****
>
> if so what kind of roadmap is there to replicate current JIT
> functionality. ****
>
> In my case in relation to function level (re)compilation.****
>
>  ****
>
> I appreciate everyones efforts, and that we all have our own agendas.****
>
> I'm just trying to put my own roadmap in place.****
>
>  ****
>
> Cheers,****
>
> Andrew.****
>
> ** **
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130215/9484f9ed/attachment.html>