harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Blackburn <Steve.Blackb...@anu.edu.au>
Subject Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/
Date Sun, 22 May 2005 23:22:59 GMT
Dan Lydick wrote:

>From: <acoliver@apache.org>
>>>2. There are no Java virtual machines period that are presently 
>>>practical to run high volume production code.
>>I meant Java virtual machines written in Java...  sorry
>Does anyone have any benchmarks on such designs?
>As a hard-core real-time and device driver guy,
>I am rather skeptical that this is anything else
>but a conflict in requirements, runtime performance
>in execution speed versus interpretability and/or
>compilability of the runtime module.
>But then again, I've only been working with Java
>at all for less than four years :-)
The discussion has been rehashed a lot of times.  I'd like to see it put 
to rest (perhaps we need a technical FAQ?).  See the end of this email 
for a brief answer anyway...*

Previously you wrote:

>- FIRST:  A basic JVM, written in C/C++, by some combination
>    of contribution, new development, and extension
>- SECOND:  JIT and/or other compile optimizations, still C/C++
>- THIRD:  Other JVM speedups, in concert or concurrently
>    with a JIT compiler, still C/C++.
>- FOURTH:  Potential rewrite of key portions into Java.
Let's not lock ourselves into an implementation technology (C/C++ in 
your post here) without a deep understanding of the alternatives.  There 
are people at the table with that experience.

The "seeding" proposal is intended to address this very concern and 
acknowledge the reality that people will come to this project with 
different backgrounds and different experiences.  If we can learn from 
the wealth of technology on the table through the seeding process, I 
think we'll be able to make much more informed decisions about how we 
want the core/s of the Harmony VM to look.



<digression and rehash on java-in-java implementation technology>

* In a nutshell, for a high performance VM, the single biggest issue is 
the quality of your compiler/s (which dictates the performance of user 
code)---this is true regardless of the implementation language.  Very 
little runtime is actually due to the execution of the VM per se 
(perhaps 10%) and that is primarily just the execution of the JIT and 
the GC.  The remaining 90% is user code (and libraries) whose 
performance rests largely on the quality of your JIT.  We've 
demonstrated the performance of MMTk and I've already said many times on 
this list why the lack of implementation/implemented language impedance 
helps us so much.  As for the JIT, we have the "eat your own dogfood" 
phenomena: if the JIT is any good, then writing the JIT in Java won't be 
a performance problem.  We've seen this with the Jikes RVM project.  
Dave Grove has a work list as long as his arm of things we could do to 
improve in the optimizing compiler, but we lack the resources to get 
them done.  That is why Jikes RVM is currently lagging the commercial 
JITs where it once was competitive.   I think this is why the harmony 
project holds a lot of promise: it will sharpening the community's focus 
and lead to much better  targeting of resources.

We don't have any published performance comparisons.  I can only tell 
you that for a long time our comparison point was the IBM product VM (on 
PPC) and for a while we were competitive.  Since we no longer have full 
time IBM staff working on the project (they've been diverted to the 
product ;-), we've started to slip.  The story on the IA32 is less 
pretty mainly because our primary focus for much of the time was on the 
PPC, so a lot of trivial (but time consuming) IA32 optimizations are yet 
to be done.

As to Andy's comment to which you were responding, there is nothing 
about the Java-in-Java VM design which is preventing it from being used 
"to run high volume production code".  Jikes RVM performs very well in 
this context and that is exactly where it first made its mark 
(outscaling commercial VMs running JBB on large SMP boxes).  The two 
primary issues holding it back today are a) keeping the compiler up to 
speed with the commercial VMs, and b) completeness of the VM.  To the 
extent that either are limitations, they are due to resource constraints 
and have nothing whatsoever to do with the Java-in-Java implementation 
technology.  To the contrary: in my view there is no way we'd have 
achieved as much as we have with the resources we've had if we did not 
have the considerable software engineering advantages of a strongly 
typed language.

Having said all that, the looming performance issue is locality, which 
depends on many more subtle issues and places a lot more pressure on the 
memory management subsystem (the locality properties of the allocator, 
the capacity of a copying collector to improve locality, etc, etc).

Fortunately we're not writing device drivers here, but if that's what 
you're into, you might find this (http://jnode.sourceforge.net/portal/) 
interesting, and this (http://research.microsoft.com/os/singularity/).

View raw message