Skip to main content

Tiered compilation

Posted by forax on September 5, 2010 at 12:07 PM PDT

Yesterday, an interresting patch was pushed into the hotspot compiler (JITs) workspace, with this summary "Infrastructure for tiered compilation support", exciting isn't it.

Tiered compilation in hotspot is an old dream. Hotspot has two JITs named c1 aka client JIT and c2 aka server JIT. The client JIT starts fast but provides less optimizations so it is used for GUI application. The server JIT starts more slowly but provide very good optimizations.
The idea of tiered compilation is to get the best of both compilers, first JITs the code with c1 and then if the code is really hot to recompile it with c2.

As I said, tiered compilation in hotspot is an old dream, the flag -XX:+TieredCompilation exists since 2006 but the performance was not great.

I quickly compile a new VM with the new tiered architecture and use it to run eclipse. Wow, it's impressive, eclipse is snappy, at least a lot of snappier than with the server compiler, the compilation time of some projects of mine is clearly faster. Oh, and it crashes only once :)

Then I decide to run the DaCapo Jython benchmark. Here are the result:

As you can see, performance of tiered compilation is much better than the client JIT performance.

cheers,
Rémi

AttachmentSize
tiered.png14.96 KB
Related Topics >>

Comments

Azul's JVMs use tiered compilation by default, and has done ...

Azul's JVMs use tiered compilation by default, and has done so for years. To learn more: read the technical article in http://www.jayway.com/media/28083/jayview22.pdf (page 18).

To learn more about Azul's JVMs (Vega and Zing) please visit our web site: www.azulsystems.com

Really exciting... now, when do we get it :)

Do you know if this will this appear in the next official builds, hopefully in time for JDK M10? And maybe, if we're lucky enough, included in the HSv19 port of JDK 6u23? The latter is yet another update in the desktop-boosting 6uN series, and the tiered compiler would be a wonderful addition there... I'm thinking mostly in 64-bit support: we already have some 64-bit browsers (on Windows there's IE8 and upcoming Firefox 4), but while the JRE is available in 64-bit, it carries the Server compiler only, so loading/warmup time and footprint sucks for Applets. For JAWS, it seems the 64-bit plugin2 is smart enough to launch the 32-bit JRE when both JREs are available - or maybe that's just a bug - but I don't want that; what I want is a pure 64-bit platform, but without the overweight of Server. Oh, enabling CompressedOops by default is critical too, in the browser plugin context.

What about GC and other tuning, are they biased for Server? The tiered compiler won't be that good if it serves only the needs of server apps that must start up quicker; it should also serve the needs of client apps that need to perform faster - but can't affort to consume twice the RAM because Server has much more aggressive GC parameters by default. We should have two tiered "modes", maybe "java -tiered-client" and "java -tiered-server", that would differ by the default options for all kinds of tuning that are different between Client and Server. (JVM ergonomics doesn't seem to be good enough; or, if it is, it certainly needs to evolve in the tiered VM.)

Did you measure relative performance during start-up?

Ah, FatCatAir flies again; good.
Now of course I'd hope that the tiered mode would radically improve speed during the start-up phase of many apps where the server mode waits just-too-late to try optimising at all.
The slow start-up, of, for example, Java-powered Web servers, is unfortunate.
Rgds
Damon