0

I opened a heap dump in VisualVM and some objects don't have incoming references to them. They are unreachable.

I wonder: is it OK to see them? Are they subject to a next GC and just slipped into the heap dump?

The full GC usually has 10-20 minutes intervals. Soft/Weak references are not the case.

gavenkoa
  • 45,285
  • 19
  • 251
  • 303
  • 2
    An object without incoming references is either a GC root or garbage. – apangin Oct 16 '22 at 22:10
  • Still the situation is not clear: if it is garbage why does VM understand object type / field values when it saves it to a heap dump... I assume *there is an internal list of all allocated objects so GC knows about all past allocations* even if they are no longer referenced via a JVM programming model. – gavenkoa Oct 16 '22 at 22:30
  • 2
    When dumping heap, JVM sequentially scans all objects one by one, whether garbage or not. – apangin Oct 16 '22 at 23:08
  • How did you capture the heap dump? If you used jmap, did you pass the "live" option? – boneill Oct 17 '22 at 00:53
  • 2
    The object allocation in a TLAB is very simple: there’s just one object after the other. Therefore, it’s easy to dump all contained objects by running through it. – Holger Oct 17 '22 at 07:22

1 Answers1

0

jmap has an option to control that controls should a dump contains unreachable objects:

-dump:[live,]format=b,file=<filename>

Dumps the Java heap in hprof binary format to filename. The live suboption is optional. If specified, only the live objects in the heap are dumped. To browse the heap dump, you can use jhat (Java Heap Analysis Tool) to read the generated file.

This indirectly tells that a heap dump could contain unreachable objects.

jcmd syntax is:

jcmd $PID GC.heap_dump -all -overwrite -gz $FILE.hprof.gz

The flag -all adds dead objects, by default only live. Unlike for jhat where all are by default.

Seems TLAB (Thread Local Allocation Buffers) has nothing to to with a heap dump, it is only a special per thread area for a young generation.

gavenkoa
  • 45,285
  • 19
  • 251
  • 303
  • 2
    Nobody said that TLABs were part of a heap dump. In [this comment](https://stackoverflow.com/questions/74089183/#comment130815472_74089183) you asked “*if it is garbage why does VM understand object type / field values when it saves it to a heap dump*” and the answer to this comment is that the heap organization is simple enough to allow scanning, e.g. the Eden space consists of TLABs which contain just one object after the other. So contrary to your assumption, there is no “internal list of all allocated objects”. – Holger Oct 18 '22 at 08:30
  • @Holger Got it, thx. TLAB is managed by moving pointer to free space, so each object is one after the other. Each object has a header so you can resolve the type and thus the size, machine code demonstrating such structure is in the blog: https://shipilev.net/jvm/anatomy-quarks/4-tlab-allocation/ Organization in the young/old gen heap is different but TLAB demonstrates the point. – gavenkoa Oct 18 '22 at 09:13
  • 1
    @Holger I'd agree with OP that TLAB is not relevant here. No matter if an object is allocated in TLAB or not (e.g., `-XX:-UseTLAB` disables them entirely), the JVM knows how to traverse heap. – apangin Oct 18 '22 at 19:15
  • 2
    @apangin it only served as an example of an actual allocation strategy that explains why the objects can be dumped including the dead objects. Other allocation strategies may allow this as well, but not every JVM is capable of traversing dead objects. – Holger Oct 19 '22 at 06:35