[LLVMdev] VMKit build problems; can't use LLVM3.4.2 ?

Brian Faull bfaull at cog-e.com
Wed Jul 23 06:31:10 PDT 2014


Hi Gaël, Renato -- 

Thanks very much to both of you for the response.  I appreciate the fact that VMKit exists, and understand pegging against a release, and the current development situation.

As I said in my original email, I'm certainly willing to contribute to this or something related.  That said, I'm interested in a (very) narrow subset of VMKit... so I want to first be sure that I'm barking up the correct tree!  If this gets into a deeper discussion, we could take it off-list.

My current goal is to explore AOT compilation of Java for the LLVM system.  Is anyone doing this or interested in same?  Is VMKit's vmjc the right option?

I saw a few options:
* DragonEgg
 => using GCC parsers as front-end (i.e., gcj)
 => but http://dragonegg.llvm.org says Java support is poor.
* LLVM java-frontend 
 => https://llvm.org/svn/llvm-project/java/trunk/docs/java-frontend.txt but not listed on the LLVM projects page
 => this project looks stale or abandoned; last commit in 2007? (am I wrong?).
* Zero and Shark 
 => http://icedtea.classpath.org/wiki/ZeroSharkFaq
 => Intended for JIT, not much information available, looks stale (2011).
* VMKit's vmjc 
 => looks like it is current and functional
 => .class => .ll translation is a reasonable path.

So, my questions are rather broad at this point:
* How many use or depend on VMKit / vmjc?  If it's in broad use, perhaps this is a good path.
* Is there something better for the narrow application of AOT for Java?

If the answers to the above are reasonable, let's talk more about specifics...

Brian



On Jul 22, 2014, at 11:53 AM, Gaël Thomas <gael.thomas00 at gmail.com> wrote:

> Hi Brian,
> 
> The development of VMKit is a little bit stuck because we don't have
> any contributor. Basically, I'm alone on the project and I don't have
> any time for development (the engineers and PhD students that were
> involved in the project are all gone).
> 
> As you can see, we only support LLVM 3.3. If you are interested in
> helping porting VMKit for a newer version, I can help to explain how
> VMKit is designed and to explain how the tricky parts of the code
> work? Otherwise, I have started an implementation of VMKit for MCJIT
> and a newer version of LLVM one year ago (branch mcjit), but I'm
> unable to find any time to continue since january. But it means that I
> know what we have to do to follow the last changes made in LLVM :)
> 
> So, if you are interested in contributing, just tell me.
> 
> See you,
> Gaël
> 
> 
> 
> 
> 
> Le 21 juil. 2014 23:19, "Renato Golin" <renato.golin at linaro.org> a écrit :
>> 
>> On 21 July 2014 21:33, Brian Faull <bfaull at cog-e.com> wrote:
>>> Incidentally, this seems to be the same behavior/problem as reported on 20 January 2014 by neoedmund (http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-January/069558.html), which is solved by building using LLVM3.3 (no response seen).
>> 
>> Hi Brian,
>> 
>> It's common for some projects to attach themselves to a specific
>> version of LLVM when the team doesn't have time to merge their code to
>> trunk every other week, which can be very costly in the long term.
>> However, any project that aims to be relevant in the LLVM community
>> has to follow trunk, not a specific release, not even the current
>> release. On projects whose aim is to present a proof-of-concept or to
>> focus on a completely unrelated issue (VMKit, LLVMpipe), this seems to
>> be the choice to stick to a release or even an SVN revision number.
>> But for any compilation tool, it should never be.
>> 
>> LLVM APIs do change considerably, even between a few commits apart.
>> So, even if you support 3.5svn trunk, you can become obsolete in a
>> matter of weeks. This dependency cannot be solved by LLVM supporting
>> old APIs, or the code would have more legacy than features, and has to
>> become a motto of the side projects themselves. Thus, unless VMKit
>> developers are willing to follow trunk and have buildbots following
>> the rest, it won't happen.
>> 
>> Of course, as with any open source project, *you* could be the person
>> to drive this, in case other VMKit developers are unwilling to take
>> the extra work. :)
>> 
>> cheers,
>> --renato
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev





More information about the llvm-dev mailing list