JXRay 2.7 update 9 released

Posted on November 11, 2020

This version contains the following improvements and fixes: Added detection and explanation of several common problemsSeveral usability improvementsImproved performance, especially when analyzing dumps with a large number of objects

What’s wrong with big objects in Java?

Posted on October 20, 2020

Here is our most recent article explaining Humongous objects in the G1 Garbage Collector, and what’s bad about them.

JXRay 2.7 update 8 released

Posted on September 14, 2020

This version contains the following improvements and fixes: A new problem category added: potentially Humongous objects, as defined by the G1 garbage collectorDetection and explanation of some common, easy-to-fix problems, such as underutilized Jetty HTTP header cachesFaster processing of very big heap dumps when JXRay’s heap is relatively tightMore accurate analysis of off-heap memory usage by DirectByteBuffersAssorted 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