JVM performance article

[Will Glass-Husain <wg...@forio.com>]

Hi,

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.

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

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

Best,
WILL

Re: JVM performance article

[jh...@uoguelph.ca]

I'm a lurker on this list too and also quite new to the concepts of implementing
a jvm.  I had previously read that article on osnews.com but aside from some of
the discussion on threading in Swing I've actually learned more about most of
the topics simply by reading the discussions here.  Granted, it takes more time
but I really enjoy having the opinions of all these knowledgeable folks :)  I've
particularly enjoyed your summary posts, Steve, and if time permits I plan to
dive into some the links you've provided.

Now back to lurking, I'll come out of the cracks when I see an area where I feel
qualified to help ;)

Quoting Steve Blackburn <St...@anu.edu.au>:

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

Re: JVM performance article

[Steve Blackburn <St...@anu.edu.au>]

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