0

I'm analyzing .phd dump written by IBM JVM with Eclipse MAT.

The view named "gc_roots" displays the following list:

enter image description here

Can I be sure that the list of GC roots is complete?
Does it mean all local variables in stack of running threads are included in "Unknown" section?

Why it was named such BTW?

My doubts about completeness of GC roots list are based on the fact that heap contains several pretty big weakly-referenced char buffers at the moment when OOM is thrown. Which looks to be a violation of the contract, as even SoftReferences must be cleared before OOM.

UPDATE

Here is a list of GC roots from core dump written at the same time, which makes the things even less clear for me. enter image description here

There is no "Unknown" section, but "JNI Global" appears instead. And I still wonder where could be local variables from the stack.

user3714601
  • 1,156
  • 9
  • 27
  • Those buffers are likely kept alive by some other objects referencing them. The list of gc roots should be complete, barring major bugs in the JVM. If it *weren't* complete it would imply that the JVM leaks memory which of course is not good. – Björn Lindqvist Oct 28 '17 at 01:12
  • Accordingly to the both dumps, there is no other GC root path, only a one through a ThreadLocal, containing WeakReference. – user3714601 Oct 28 '17 at 11:00
  • But why do you think that missing some GC roots here means a leak? – user3714601 Oct 28 '17 at 11:00
  • You are using some JVM option to generate the heap dump when the OOME is thrown, right? Otherwise the reachability of objects could change in the meantime, e.g. because the stack is unwound by the throw. – the8472 Oct 28 '17 at 11:33
  • Yes, exactly, the dumps are generated automatically on OOME. – user3714601 Oct 28 '17 at 11:36

1 Answers1

0

Last-ditch collections are not applicable to some OOME-causes. For example allocation attempts larger than the maximum heap size obviously can never be satisfied and no collection will change that.

You should check the message property of the OOME.

And I still wonder where could be local variables from the stack.

Presumably the Thread category.

the8472
  • 40,999
  • 5
  • 70
  • 122
  • The message was simply "Java heap space". But I do not think there was any unexpectedly big allocation request. At max it could be the same as one of the dozen buffers in the heap, that should be collected accordingly to the dump. – user3714601 Oct 28 '17 at 11:25
  • Is the OOME consistently thrown at some specific or a few related callsites? Or at random locations? – the8472 Oct 28 '17 at 11:31
  • Random locations, and never repaired from that. So finally support guys have to restart JVM. – user3714601 Oct 28 '17 at 11:35