harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Hind <hi...@us.ibm.com>
Subject Re: JVM performance article
Date Sat, 04 Jun 2005 04:03:37 GMT
Steve Blackburn wrote:

> 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 agree. 

Dave's talk and the tutorials Steve has referred to also debunk a popular 
myth that, unfortunately, the osnews article above further promotes: that 
the JIT kicks in the first time a method is executed.  This is NOT true in 
any of today's high performing JVMs because the compilation "burp" would 
be too noticeable in large applications, like eclipse, that have thousands 
of methods that execute infrequently.  (However, this myth was true in the 
early Smalltalk, Self, and Java VMs, but that was over a decade ago.)

Instead, modern JVMs try to balance these compilation burps by using a 
strategy (selective optimization) that tries to ensure a method really is 
important enough to invoke the JIT on.  This is often done by counting the 
number of times a method is called and is sometimes augmented with a loop 
count for the method (in case the method is called infrequently, but 
nevertheless a good chunk of execution time is spent in.)  When this cheap 
profile indicates a method is important, the JIT is used to improve the 
generated code.  Other systems use infrequent sampling (100/sec) of the 
call stack to find candidates to be JITed.  Many such systems also use 
multiple levels of JIT optimizations (similar to a static compiler) 
depending on how important the method appears at runtime.  Jikes RVM uses 
the sampling to plug into a simple cost/benefit model to determine what 
level (if any) of the JIT to use.

Using a selective compilation strategy typically results in only about 20% 
of the executed methods being highly optimized.  However, when life is 
good, these 20% represent a large (>95%) of the execution time, so this 
strategy has been shown to be better performing that the compile on first 
execution approach.

So how are the other ~80% of the methods executed? 

They are either interpreted or compiled to native code with a very quick, 
but poor code quality producing compiler (yes, you can think of it as a 
dumb JIT).  Some systems (Sun HotSpot, IBM DK, IBM J9) use an interpreter, 
other systems (JRockit, ORP, Jikes RVM) use a cheap compiler.


View raw message