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 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
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