Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <42A0AD84.9000407@anu.edu.au>
Date: Sat, 04 Jun 2005 05:20:36 +1000
From: Steve Blackburn <Steve.Blackburn@anu.edu.au>
User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: JVM performance article
References: <035001c56860$c5b0e1e0$6500a8c0@Apollo>
In-Reply-To: <035001c56860$c5b0e1e0$6500a8c0@Apollo>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Will,

> As a lurker on this list, I thought I'd share the following article:
>
> http://www.osnews.com/story.php?news_id=10729
>
> This might be a good article for those new to JVMs.  It's not as 
> technical as the various white paper citations being bandied about but 
> it's a nice introduction to just-in-time-compiling / optimization, 
> Swing threading, and other JVM performance-related issues.

Yes.  I think this is a nice and high level overview.  These subjects 
(almost exactly) are covered in greater depth in the various links I've 
posted, most particularly in the talk by Dave Grove and others which I 
posted most recently.  If any readers found Will's post interesting, I 
*strongly* encourage you to read the following for more on the *how* and 
*why*...

> I've just added another tutorial to the wiki.  This is a great talk 
> which Dave Grove (IBM Research) gave at U Texas a few weeks ago.  For 
> those interested in performance related issues and VM design, I'd 
> regard this as "essential reading".  :-)
>
> http://www.research.ibm.com/people/d/dgrove/talks/SoftwareOptimizationAndVirtualMachines.pdf 
>

Skipping to the bottom of your email...

> I assume these will all be goals for a Harmony project JVM?

Absolutely!  Most of the ideas you mentioned is already implemented in 
Jikes RVM's opt compiler, and I think most likely in ORP's compiler, 
even the more out-there ones, such as OSR (on-stack-replacement) and 
guarded inlining.  This is the sort of work Harmony is trying to 
leverage, so it would be a failure of the project if it did not achieve 
these goals!

This technology is very exciting and I'd encourage interested list 
readers to read the article you pointed to, read the tutorials, and ask 
questions! :-)  Understanding the implications of this technology is 
important to understanding how Harmony will work and where the future of 
VMs are headed.

Cheers,

--Steve

>
> "I think Java is somehow still seen as an interpreted language; in 
> fact, it does get compiled to native code using Just In Time (JIT) 
> compilation. It is also a myth to think that JIT code is slower than 
> pre-compiled code. The only difference is that bytecode gets JITed 
> once its required (i.e., the first time a method is called - and the 
> time is negligible) it then gets cached for subsequent calls. JIT code 
> can benefit from all the same optimisations that pre-compiled can get, 
> plus some more (from Lewis and Neumann, 2004):
>
> * The compiler knows what processor it is running on, and can generate 
> code specifically for that processor. It knows whether (for example) 
> the processor is a PIII or P4, if SSE2 is present, and how big the 
> caches are. A pre-compiler on the other hand has to target the 
> least-common-denominator processor, at least in the case of commercial 
> software.
>
> * Because the compiler knows which classes are actually loaded and 
> being called, it knows which methods can be de-virtualized and 
> inlined. (Remarkably, modern Java compilers also know how to 
> "uncompile" inlined calls in the case where an overriding method is 
> loaded after the JIT compilation happens.)
>
> * A dynamic compiler may also get the branch prediction hints right 
> more often than a static compiler."