In Java terminology, the “live set” (LS) for a given running app means all objects that are live (that is, not garbage) at the given moment. For most apps with steady workload, objects come and go from the live set, but its size remains pretty stable (after initial warmup). In contrast, if LS keeps growing, the app most likely has a memory leak.
If LS size is too close to the maximum heap size (value of -Xmx flag), the JVM has little memory left to accommodate short-lived objects and has to perform GC frequently, which is bad for performance. On the other hand, setting the heap much bigger than LS may waste memory and sometimes cause other problems due to very infrequent GC. That’s why it is important to measure your LS size and set your heap accordingly. For most Java apps, the optimum heap size is 2.5…5x LS size. The exact ratio depends mainly on allocation rate: the more objects per second are allocated, the bigger heap is needed to perform GC more optimally.
A JXRay report contains LS size in section 1, in the second table from the top. The “Live Bytes” cell, which is 83,604Kb in the example below, is what you need:
Heap dumps currently don’t contain explicit information about maximum heap size. However, in the future we plan to implement a workaround, which will allow apps themselves to store this and other useful information in the dump. After that, JXRay will be able to tell you right away whether your heap is too big or too small given your LS size. Stay tuned!