runtime JVM options

[Peter B. Kessler]

Victor Cheung wrote:
> Thank You, Peter!  I was just testing each option right now to
> determine which lines they print... then I saw your reply!  (I kept
> -Xloggc in JBoss, then added each additional option one by one,
> starting JBoss and then stopping, then looking at the gc log file to
> see what the option printed out)
> 
> Our production server has 8 CPUs, 32GB memory.
> 
> Why is "PS YoungGen" = -XX:+UseParallelGC ?  I didn't specify to use
> any particular collectors, and after all the reading I did, I would
> have guessed the default young generation collector to be the CMS.
> Is CMS synonymous with "Concurrent Low Pause Collector"?  I'm
> somewhat still confused because I'm noticing a lot of the
> JVM/tuning/GC literature are written by different people at different
> times and terms are being interchanged casually as if the reader is
> supposed to know.  I'm also trying to filter out what is no longer
> relevant because the JDK has evolved.  Sorry to digress.
> 
> Back to my original point, when you said "PS YoungGen" = "parallel
> scavenge" (-XX:+UseParallelGC) this makes sense because of the
> acronym "PS" = "Parallel Scavenge".  But if it's true that "PS
> OldGen" = "serial old generation collector" then this is confusing!
> It should be changed to "Serial OldGen".  Anyhow, what is the
> difference between -XX:+UseParallelOldGen and -XX:+UseConcMarkSweepGC
> ?  From my reading I was leaning toward using -XX:+UseConcMarkSweepGC
> for handling the old generation heap.

HotSpot has 10 years of history built into it.  You are right that -XX:+UseParallelGC seems like it ought to turn on parallel young and parallel old collectors.  The problem was that we wrote the parallel young collector before we knew how to write the parallel compacting collector.  So we needed a flag to turn on the parallel scavenger, and by the time we wrote the parallel compactor customers had gotten used to -XX:+UseParallelGC turning on only the parallel scavenger, so we had to add a new additional flag to turn on the parallel compactor, -XX:+UseParallelOldGC.  Backwards compatibility matters.  (That's not an excuse for not thinking about forward compatibility when naming flags.  Sigh.)

> Wow.  The GC output descriptions for CMS is really messed like you
> said...
> 
> The whole purpose of me diving into this JVM world (my original goal)
> is to fix the "OutOfMemoryException GC overhead limit exceeded".  And
> I'm hoping to find a simple solution to this.  One that is not too
> prescriptive in terms of the options needed.  Ideally, I do not want
> to have to specify anything related to survivor spaces, the permanent
> generation heap, or anything else but the following:
> 
> - Xms - Xmx - type of young generation collector - type of old
> generation collector - XX:NewRatio (for controlling size of young and
> old generation)
> 
> IMHO, if all there was to tuning the JVM was at most the above,
> everyone would be happy!  With so many options available it's really
> flexible, but the price is complexity.  From my perspective, this is
> another classic Pandora's Box scenario.  Do people out there really
> need to fine-tune JVMs so precisely (how do people get to tinker that
> much with production systems anyhow... because at a certain point it
> becomes an exercise in trial-and-error... and is it worth the
> time/risk/effort in squeezing every last bit of performance from a
> JVM when hardware is cheap these days)?  I'm no expert or anything,
> but I really think the design of the JVM tuning options needs to be
> reconsidered (since it seems that the current path is only to add
> more options, not take away).  There is value in the old adage "less
> is more", especially when the programming movement is clearly toward
> simplicity (DSLs, meta-programming, dynamic languages, etc.).  Java
> needs to be simpler, not more complicated (assuming it's not too late
> already).
> 
> I apologize, I'm really digressing.  Bed time for me!
> 
> Thanks though, Peter (and everyone else who's helped)!
> 
> 
> victor

I completely agree with your sentiments.  If we were delivering a new product we might have the luxury of thinking things through and making it all consistent and beautiful.  But as they say: we are building the airplane while its flying, so we do what we can without breaking anything crucial (like our customers).  As an example: We still get grief over the decision to turn on the parallel scavenger instead of the serial scavenger when running on a multi-processor machine, even though the parallel scavenger out-performs the serial scavenger on any multi-processor.  For another example, you might not like it if (when!) we introduce a new collector and decide to make it the default: you will have tuned your application against your hardware (and data!) until you are happy, and then we go and change some policy that makes you have to retune.  We would like to move to a style where you describe the qualities of service you need (pause time, throughput, etc.) and we pick the colle
ctor(s) that are right for your application while watching it run.  But we aren't there yet.  We don't get to know beforehand whether we are running an applet on an old laptop or JBoss on an 8-way machine with 32GB of memory, so we need you to specify some command line options.

For more background reading on the collectors, tuning, blogs, etc., follow the links at http://java.sun.com/javase/technologies/hotspot/gc/index.jsp.

I'd be disappointed if JBoss didn't have some suggestions on how to tune the various JVMs to run their product well.  I have no experience with tuning JBoss.

			... peter
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use