From michael.finocchiaro at gmail.com Mon Dec 20 05:22:36 2010 From: michael.finocchiaro at gmail.com (Michael Finocchiaro) Date: Mon, 20 Dec 2010 14:22:36 +0100 Subject: Questions on a few Java6 -XX options Message-ID: Hi everyone, Just wondering why on the "official" list of -XX options here: http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html why -XX:+UseCompressedOops is not listed? I noticed a few bug reports...is this option safe for production use? Also, are there some performance numbers to +UseStringCache, -XX:+UseCompressedStrings and/or -XX:+OptimizeStringConcat? Any white papers I could study? I thought that -Xmn was preferred over -XX:NewSize / -XX:MaxNewSize because of the fact that -XX:NewRatio gets over-ridden by lots of other options including -XX:SurvivorRatio and +UseConcMarkSweepGC... Thanks in advance, Fino Michael Finocchiaro michael.finocchiaro at gmail.com Mobile Telephone: +33 6 85 46 07 62 MSN: le_fino at hotmail.com Twitter: le_fino Blog: http://mfinocchiaro.wordpress.com Bookmarks: http://del.icio.us/michael.finocchiaro -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20101220/1d6568a4/attachment.html From Brian.Harris at morganstanley.com Mon Dec 20 09:02:33 2010 From: Brian.Harris at morganstanley.com (Brian Harris) Date: Mon, 20 Dec 2010 12:02:33 -0500 Subject: accessing memory management details Message-ID: Hello, Is it possible for my app to learn where objects are allocated? Young or old generation, if young which survivor space? In a LAB? I'm interested in where an object was initially allocated, but also any movements (from where?, to where?, when?) that happen thereafter. These use cases illustrate what I had in mind: * JUnit test asserting >90% of allocations of type com.mycompany.Entity are done in TLAB * Benchmark tool showing the effect that various JVM tuning parameters have on memory management. Displayed as graphs, timelines, etc. I looked through the 1.6 JVMTI demos and didn't see these sort of details being exposed. Also nothing similar looking through BTrace examples. Where should I look next?. Happy holidays, Brian Harris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20101220/bb642c44/attachment.html From Alexander.Livitz at on24.com Mon Dec 20 11:53:33 2010 From: Alexander.Livitz at on24.com (Alexander Livitz) Date: Mon, 20 Dec 2010 11:53:33 -0800 Subject: Questions on a few Java6 -XX options In-Reply-To: References: Message-ID: <4C717D4720DE704383A5D24A4D46E1C681D339AA91@P-HQEXCHANGE.on24.com> BTW, even -XX:+UseCompressedStrings is published as valid flag, the 1.6.0-21 JVM on Solaris SPARC 64bit fails to start with it. Anybody knows why? Is it a known bug? Thanks, Alexander From: hotspot-gc-use-bounces at openjdk.java.net [mailto:hotspot-gc-use-bounces at openjdk.java.net] On Behalf Of Michael Finocchiaro Sent: Monday, December 20, 2010 5:23 AM To: hotspot-gc-use at openjdk.java.net Subject: Questions on a few Java6 -XX options Hi everyone, Just wondering why on the "official" list of -XX options here: http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html why -XX:+UseCompressedOops is not listed? I noticed a few bug reports...is this option safe for production use? Also, are there some performance numbers to +UseStringCache, -XX:+UseCompressedStrings and/or -XX:+OptimizeStringConcat? Any white papers I could study? I thought that -Xmn was preferred over -XX:NewSize / -XX:MaxNewSize because of the fact that -XX:NewRatio gets over-ridden by lots of other options including -XX:SurvivorRatio and +UseConcMarkSweepGC... Thanks in advance, Fino Michael Finocchiaro michael.finocchiaro at gmail.com Mobile Telephone: +33 6 85 46 07 62 MSN: le_fino at hotmail.com Twitter: le_fino Blog: http://mfinocchiaro.wordpress.com Bookmarks: http://del.icio.us/michael.finocchiaro -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20101220/41d7153e/attachment.html From todd at cloudera.com Fri Dec 31 13:24:38 2010 From: todd at cloudera.com (Todd Lipcon) Date: Fri, 31 Dec 2010 13:24:38 -0800 Subject: Monitoring CMS free list BinaryTreeDictionary statistics Message-ID: Hi all, As you may recall from some discussion this summer, I work on an app that has big problems with fragmentation, and am pretty sure there is no way to tune CMS GC to avoid eventual fragmentation and long compaction pause. So, my next best bet is to add monitoring within the application to determine when fragmentation has gotten bad. If I can determine this via some kind of metric, JNI, or undocumented API, I can have the server take corrective action. In particular, since it is a distributed system, I can shed load from the fragmented server gracefully, initiate a compacting GC (or full JVM restart), and then pick the load back up. This is vastly preferable to a 30+second GC pause! The -XX:PrintFLSStatistics=1 option shows the fragmentation very clearly in the GC log. I can see the average block size and max chunk size in the old gen free list steadily drop until the point where promotion fails and a compacting pause happens. Is there any way to get at these two statistics short of modifying the JVM itself (and other than gc-logging into a named pipe)? It seems like the kind of thing that would be useful for operators even outside of my fragmentation-happy application. -Todd -- Todd Lipcon Software Engineer, Cloudera -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20101231/02f90155/attachment.html