[LLVMdev] [VMKit] 2.9 or ToT? Java version/features?

[Nicolas Geoffray]

Hi Will,

On Mon, Aug 15, 2011 at 4:17 AM, Will Dietz <willdtz at gmail.com> wrote:

> Hi Nicolas,
>
> Reviving old thread of sorts... thank you very much for your earlier
> response--I apologize for not responding to tell you how very helpful
> your information was!  Didn't come back because you gave me everything
> I needed at the time :).
>

Great!


>
> Anyway:
>
> On Fri, May 13, 2011 at 2:00 PM, nicolas geoffray
> <nicolas.geoffray at gmail.com> wrote:
> > On Fri, May 13, 2011 at 7:30 PM, Will Dietz <willdtz at gmail.com> wrote:
> > Today you can use both. I haven't improved vmkit much lately, so version
> 2.9
> > and TOT are pretty much the same.
>
> Looking at the vmkit-commits mailing list, seems like you've
> changed/are changing a lot.
>
>
Yes. A few things I wanted to implement but didn't have the time before.


> Is ToT generally stable enough for use in my projects, or should I
> wait for a release?
>

It should be stable enough.


>
> >>
> >> --What features of Java does VMKit support? Is there a corresponding
> >> java 'version' (1.4, 1.6, etc) that VMKit supports? (Is this
> >> documented somewhere? I was unable to find it)
> >
> > It implements the VM spec version 2 (+ some features of version 3 which
> is
> > still unofficial). It uses  GNU Classpath for the base library, so the
> java
> > version you're mentioning will be the one implemented in GNU Classpath,
> and
> > that is 1.6 (with still some unimplemented feature of 1.6). But vmkit
> does
> > not to have to be tight to a base library implementation. An interesting
> > project to work on would be to support the OpenJDK library.
>
> Supporting OpenJDK is very interesting indeed, as full 1.6 support is
> important to us.  How intense of a project would undertaking this be?
> And is this something you could semi-mentor on if I were to undertake
> it? :).
>

Yes, no problem. I'd be happy to help in any way if you were to implement
it. And I'd *really* want this to happen. GNU Classpath is not evolving
anymore, and still has some compatibilities/performance problems.

I don't know how decoupled from the runtime the OpenJDK libraries are, but
on the VMKit front, it should not be too hard to replace GNU Classpath's
requirements with OpenJDK's. You just need to be really familiar with
OpenJDK on how the boot system works.


> Not sure if we'll go in this direction, but if we are to continue to
> use VMKit I think we'll have to do so.
>
> >>
> >> And since I'm feeling lucky: What's the status of VMKit? Is it still
> >> able to run tomcat, and the dacapo benchmarks (on x86 anyway)?
> >>
> >
> > Yes, it works well on a x86 machine (x64 is not supported by the GC). And
> it
> > is able to run tomcat and some of the dacapo benchmarks. There are some
> > applications and dacapo benchmarks that don't work because of GNU
> Classpath
> > being incomplete. Another reason to try to support the OpenJDK library
> >>
>
> Agreed, understood, and great news.  Especially if using OpenJDK isn't
> an impossible undertaking :).
>
> Regarding the lack of 64bit support, are there GC's that support 64bit
> that might be worth looking into?
>

Maybe. MMTk has the advantage that's is very generic and wasn't too
difficult to plug into vmkit (well except the fact that it was written in
Java - but that looked more like a technical challenge).


>
> Technically I'm not sure we need a 64bit JVM, but our tools are 64bit
> and would be ideally be integrated into the runtime...
>
>
I should re-check about the state of MMTk then. From what I remember it
could not handle 64bits, but the latest version might.


> That brings me to my last question, a new one!
>
> Is it still possible to AOT code?  I'm planning on doing (potentially
> rather expensive) static analysis on the IR form of Java code, as well
> as being worried about performance issues with using a JIT (especially
> since the LLVM JIT AFAIK doesn't do any kind of adaptive
> optimizations, etc, seems static compilation should always result in
> faster code...).
>

Yes, that's still possible, although you cannot load that
application-compiled AOT code in VMKit anymore.


> Any thoughts you can share on that (there's a precompiler now, is that
> a partial AOT?) would be greatly appreciated.
>

The precompiler is for the bootstrap classes (the ones in the core library).
It compiles the stuff (eg the whole bootstrap process of the JVM) that are
needed for faster startup of the JVM and includes it in the JVM.

I disabled support for application-compiled code because I wasn't using it,
and it was broken anyways for precise GC. If there is need for it, I think
it should be easy to put it back.


> >> Thanks for your time,
>
> Let me take this opportunity to re-thank you for your efforts and any
> insights you can offer.
>
> Thanks, and have a good one!
>
>
Thanks! And hope what I just replied helps!

Cheers,
Nicolas


> ~Will
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110816/0c53310c/attachment.html>