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

JXRay 2.7 update 7 released

Posted on July 7, 2020

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 512GSeveral scalability issues that could arise when analyzing extremely big dumps have been fixedDirectByteBuffers 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 shown on the
In short: open a JXRay report, go over the “red flags” in it, find the one(s) that will give you the biggest bang for the buck and change your code accordingly. Each JXRay report contains is a list of all possible problems / optimization opportunities, but in each heap dump a given problem may or may not cause much waste. So once you obtained a report, you should first find problems that cause maximum waste
Boxed numbers are objects such as java.lang.Integer, java.lang.Float etc. Each such object is allocated on the heap, contains all the standard internal “bookkeeping” data that the JVM needs, and therefore takes much more memory than its “payload” value. For example, a plain int number takes 4 bytes, but an instance of java.lang.Integer takes 16 bytes in most JVM implementations. Boxed numbers were introduced mainly to support “numeric” elements in collections such as ArrayLists or HashMaps.