harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Archie Cobbs <arc...@dellroad.org>
Subject Re: I hope the JVM implements most using Java itself
Date Wed, 11 May 2005 15:15:43 GMT
Robin John Garner wrote:
>>Yes, and this brings up an important point: the VM should be designed
>>to allow code execution to easily transfer between compiled C/C++ code
>>and JIT'd (or whatever) Java code. This is in some sense already a
>>requirement anyway because of things like user-defined class loaders.
> This is a tricky issue.  One of the nice things about gcj is the CNI
> interface between Java and C++ - the ability to switch seamlessly between
> Java and C++ is great when interfacing code written in both languages. 
> This  does however come at a cost.
> Firstly, the inherent safety of Java means that you can use memory
> management techniques (copying garbage collectors) with the accompanying
> performance advantages.  While it is possible to do copying collection in
> a restricted subset of C/C++ if you have the necessary compiler support,
> this isn't exactly the seamless integration that is desired here.

That's a good argument against copying collectors in my opinion :-)

But this brings up a good example of what I was talking about earlier
about how a VM cannot always easily be "modularized" without penalty.
Imagine your execution engine (or whatever you call it) makes the
assumption that object references are direct and don't change, for
the naturally desirable reason that it wants to be fast. Then along
comes somebody who says, "Hey, I want to implement a copying GC!"
Oops, then what?

The alternative is to make your execution engine support BOTH direct
and copying GC's. But that sounds pretty slow (or at least pretty
complicated) to me.

> Secondly, JIT compilers have various performance advantages over their
> ahead-of-time peers, and in particular library code can be inlined into
> user applications at run time.  This advantage is lost when crossing a
> language boundary (unless the C compiler can emit Java bytecode :-).

Again showing my JC bias here, but this is a weak argument IMHO. Much of the
bytecode that a VM will execute in a normal application is not actually
"application" code but core classes and libraries like Xerces, etc.

This code can be agressively optimized (including inlining, array bounds
check elimination, nonvirtualization, etc.) by a WAT compiler.. JC being
a perfect example. Not to mention the application itself. After all,
who only runs an application once? You can WAT compile the application
and then all of your code (except for anything loaded & run dynamically
at runtime) will run fast.

Of course, there's no reason a JVM couldn't have both a JIT compiler
and a WAT code generator... then you'd get the best of both worlds.
All you'd need is to generate code that follows the same conventions.


Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com

View raw message