Author: Mikhail Dmitriev

Here is our most recent article explaining Humongous objects in the G1 Garbage Collector, and what’s bad about them. https://dzone.com/articles/whats-wrong-with-big-objects-in-java

This version contains the following improvements and fixes: A new problem category added: potentially Humongous objects, as defined by the G1 garbage collector Detection and explanation of some common, easy-to-fix problems, such as underutilized Jetty HTTP header caches Faster processing of very big heap dumps when JXRay’s heap is relatively tight More accurate analysis of off-heap memory usage by DirectByteBuffers Assorted bug fixes

To generate a heap dump, you typically use the jmap utility, for example: > jmap -dump:live,format=b,file=mydump.hprof <JVM pid> Note the “live” flag above: it forces the JVM to perform a Full GC before generating the dump. If this flag is omitted, no GC is performed and the resulting dump may contain (a lot of) garbage. Which kind of a dump is preferable? Oftentimes, garbage objects are less important than the live ones. Modern GCs are …

Applications that run with multi-hundred-GB heaps are rare, but they do exist. However, most of the existing tools are unable to analyze heap dumps bigger than ~150G. That’s because internally in those tools, each object in the dump is assigned an integer id, with a maximum value of 2^31, or slightly more 2 billion. Statistically, in a typical heap dump an average object takes 70-80 bytes, which results in the above limitation. JXRay, however, can …

Today we released JXRay 2.7u7. This version contains scalability and usability improvements, including, but not limited to: Maximum size of heap dump that the tool can analyze increased to 512G Several scalability issues that could arise when analyzing extremely big dumps have been fixed DirectByteBuffers for which native memory has been released explicitly are handled correctly now. Thread stacks are grouped such that the threads that are most likely to do some CPU work are …