 |
Search |
 |
||||||
|
Rémi Forax  Rémi Forax is Maitre de Conférence at University of Marne-la-Vallée since 2003 where he obtained his PhD on multi-method in Java. He has been using Java for many years and enjoys himself hacking the JDK. Rémi Forax's blogTiered compilationPosted 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. 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,
»
Related Topics >>
Blogs Comments
Comments are listed in date ascending order (oldest first)
Did you measure relative performance during start-up?
Submitted by damonhd on Mon, 2010-09-06 01:25.
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
|
|
Recent EntriesCategoriesArchivesSeptember 2010
July 2010 June 2010 May 2010 February 2010 January 2010 December 2009 November 2009 October 2009 September 2009 August 2009 July 2009 June 2009 May 2009 April 2009 February 2009 January 2009 December 2008 November 2008 October 2008 September 2008 July 2008 May 2008 April 2008 March 2008 February 2008 January 2008 November 2007 October 2007 September 2007 August 2007 July 2007 June 2007 May 2007 March 2007 February 2007 January 2007 December 2006 November 2006 October 2006 September 2006 August 2006 July 2006 |
||||
|
|||||||
|
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.)