Using a fast approach to see the heap
Sometimes taking a heap dump will be too long for the production environment, on this cases, it is possible to wait for the load to reduce and then take the heap dump.
However, it is possible to use the quick java diagnostics tool to see the some quick information.
If one does `GC.class_histogram`, which does not depend of +UnlockDiagnosticVMOptions, it can see the list of instances and retention based on the heap usage, example:
GC.class_stats$ jdk-11.0.1/bin/jcmd 1568 GC.class_histogram 1568: num #instances #bytes class name 1: 2725548 87217536 java.util.HashMap$Node 2: 101237 56724056 [B 3: 2706313 43301008 org.infinispan.server.some.Class <--- some clas takes 433k bytes, so then 43mb 4: 13443 17843296 [Ljava.util.HashMap$Node; 5: 21725 16866280 [Ljava.lang.Object; 6: 8658 5679648 io.netty.util.internal.shaded.org.jctools.queues.MpscArrayQueue 7: 62530 5015664 [C 8: 79376 2540032 java.util.concurrent.ConcurrentHashMap$Node
So we can see that the class `org.infinispan.server.some.Class` takes 2706313bytes, so 27mb of the heap, very easily.
This is a very powerful and pretty simple, you can use jcmd to get a heap dump with: `jcmd PID GC.heap_dump` but then you need to set a tool to analyse the Heap itself, like MAT.
Of course this quick usage is not for beginners, you need to know a bit of your application/stack so then one can see how it gets some data. But for a quick investigation it is pretty useful.
I will be presenting some quick jcmd usage in a conference: TDC. This is my second time presenting at the TDC and I’m very glad to share my knowledge on jcmd and live gc observations. In 2014 went to Florianopolis to present about EEG but now I will be presenting in Porto Alegre, RS, Brazil:
TDC 2020 Porto Alegre
I will add slides/presentation here and some extra comments right after, of course.