Friday March 30, 2007
Friday March 30, 2007
Tiered Compilation almost live
A few days ago I putback the change that now causes the server jvm (32bit) to be built as tiered. It doesn't actually enable the jvm to run tiered by default but both compilers are present and you can optionally ask for tiered. I'm still having trouble tuning my multi-tiers jvm and I decided that at the very least I ought to see what feedback there was from people adventuresome enough to try the tiered jvm. I expect that there are pathologies and that you may have to tune the thresholds a bit.
It looks like for the current schedule that this will end up in jdk7 build 12 which is still about a week away. If it isn't in b12 it will certainly be in lucky b13.
You can tell if you have the tiered jvm by running -server -version and you'll see something like:
Java HotSpot(TM) Tiered VM (..., mixed mode)
In order to actually get tiered operation you'll have to ask for it via the switch -XX:+TieredCompilation
You may also want to experiment with the compiler thresholds via -XX:CompileThreshold=<nnn> and -XX:Tier2CompileThreshold=<nnn>. Currently the thresholds are 1000/10000. I've found that 1000/35000 works ok for me. I'm curious to see where others find the best tradeoff.
Comments:
Exciting...will this land on the builds for all platforms at the same time?
Posted by Taras Tielkes on March 30, 2007 at 11:47 AM EDT #
Yes. All the platforms where we provide a 32bit server vm will be able to run tiered. 64bit server vm's don't have a client compiler available so for the moment this is 32bit only.
Posted by fatcatair on March 30, 2007 at 11:56 AM EDT #
Great news!
Any idea when/if this might be in a sufficiently settled and robust state to be moved back into the JSE6 mainline for u2 or whatever? That and a CMS Parallel Remark fix from the GC folks and I'd be in clover!
BTW, are we still limited to 1 or 2 compile threads with this putback's code? (Think Niagara.)
Rgds
Damon
Posted by Damon Hart-Davis on March 30, 2007 at 12:44 PM EDT #
Well if things go as hoped it will show up in JSE6 certainly not u2. Hard to predict which update it would be as it depends on a lot of things I have no control over.
As far as compiler threads it runs like vanilla server which is typically 2 threads. However the client compiler by design can only compile a single method at a time. So you only get more threads for server compiles (you can get simultaneous server [c2] and client [c1] compiles). You may be able to influence the number of compile threads by enabling -XX:+CICompilerCountPerCPU to get a compile thread per cpu. I can't say I've ever tried it ymmv.
Posted by fatcatair on March 30, 2007 at 01:43 PM EDT #
Hi,
Looks like that flag would allow 3 (three) C2 threads on a 24-thread (6-core) Niagara-1.
Do you feel that is too many / too few / about right (said Goldilocks)? For example, is peak memory use or even working-set size likely to be a problem with many concurrent C2 threads?
Rgds
Damon
Posted by Damon Hart-Davis on April 03, 2007 at 06:28 PM EDT #
Well my experience is that as it works now tiered tends to do too much compilation. So increasing the number of compile threads seems likely to interfere with your app. However I admit to not do much experimentation with the number of threads. I just putback a change which will also by in b12 (which is starting to look mythical at this point given how long b11 is taking) that will allow you to adjust CICompilerCount directly in product mode. So you'll be able to try any number you want.
Posted by fatcatair on April 09, 2007 at 11:18 AM EDT #
Thx...
Posted by Damon Hart-Davis on April 09, 2007 at 07:54 PM EDT #
Thanks a lot for making this happen!
Do you recommend tired-mode for long-running client apps too?
Whats about memory-footprint?
Thanks, Clemens
Posted by Clemens Eisserer on April 10, 2007 at 08:14 AM EDT #
So with the current version of tiered that you'll see inb12 I expect that long running client apps are the one you'd expect to see the best results. Assuming that your client app is running now with the client vm. The tiered system has pretty close to the same startup performance of the client vm and better performance as it run longer and code is converted to more optimized form. Apps running with server now are likely to see better startup but reduced overall performance compared to vanilla server mode. I'm still struggling with fixing this. There are a lot of complicating factors that make this harder than I expected it to be. Rather than wait for that situation the decision was made to build tiered and let people play with it and see what they get. I'm anxiously awaiting that feedback and hoping at least some people will be happy.
Posted by fatcatair on April 10, 2007 at 10:37 AM EDT #
Hi,
Can I try to understand better your "as it works now tiered tends to do too much compilation" comment?
Do you mean that HotSpot currently attempts to compile code prematurely but that that tendency is counterbalanced in practice by the compilations being queued and thus delayed? If so, can't the compilation threshold just be put back a little to achieve the same overall where there is less queueing (more CPUs)?
Or do you mean that you see the compilation taking CPU resources away from the app itself where that may not have been the best choice? Does that still apply where the app is not able to use all the available CPU resource at the time, eg not being threaded enough to use all cores in a Niagara CPU?
Rgds
Damon
Posted by Damon Hart-Davis on April 10, 2007 at 12:33 PM EDT #
Hi,
this sounds very promising! I'm very excited to try 2-tiered-compilation in b12 and see how it solves the startup problems that currently keep us from using the Server JVM. I'll let you know about the results.
Nick.
Posted by Nicolas Michael on April 24, 2007 at 07:29 AM EDT #
Post a Comment:
Comments are closed for this entry.