Hacker News Reader

Comment by rsynnott | Hacker News Reader

> All this is only worsened by the ‘black box’ nature of the optimization level switches.

JVM switches like -XX:CMSInitiatingOccupancyFraction=70 -XX:SurvivorRatio=2 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:NewSize=2048m -XX:MaxNewSize=2048m (taken from real recommended settings for an open-source project) are, of course, not opaque-to-the-average-user at all :)

View on HN

http://www.oracle.com/technetwork/java/javase/tech/vmoptions...

The page existed for over ten years (Under different domains) and countless tutorial and presentations about hotspot covered them.

Sure. There is also extensive documentation on what GCC flags do. Neither JVM flags nor GCC flags refer to deep dark secrets.

Also helpful: http://www.slideshare.net/aszegedi/everything-i-ever-learned...

You are right, but newer Java versions have what is called "GC ergonomics": you simply define either a throughput or a latency goal, and the JVM tries to dynamically change the settings until to achieve your goals.

Some applications can be pathological, in which case you are better off setting lower-level flags. For example, Lucene both churns through tons of short-lived strings and tries to maintain caches of large arrays. The memory/gc optimizer handles this very poorly.

Between modern Java tending to move caches to unmanaged memory-mapped regions as libraries mature, and the potential of G1 as a concurrent compacting collector, we're on the cusp of not having to worry about any of this anymore.

By the way, I'm not complaining about Java here. I _like_ Java (or at least I like the JVM; the language is something one puts up with, or sometimes not, for the JVM). I just don't think it's terribly fair to say that c compilers require all these arcane options for performance, without noting that JVMs have their own just-as-arcane (or maybe moreso; garbage collection is harder to wrap your head around than compiler optimisation, and can hurt you more) options which are required for performance.

If you're using the new G1 collector which ships in JDK 7, the only configuration parameters you really need to care about are the minimum and maximum heap sizes (-Xms and -Xmx) and perhaps the latency target (-XX:MaxGCPauseMillis).

So it's not all bad.

Well, this is the theory, certainly :) I haven't found it to necessarily be true in all cases.

One of my favorite tricks not often used: -XX:MaxTenuringThreshold=0

Higher throughput when you have lots of short lived objects.

Reply on news.ycombinator.com