RFR: 8299426: Heap dump does not contain virtual Thread stack references [v2]

[Alex Menkov]

On Mon, 4 Dec 2023 19:14:59 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> > My understanding that information about references is one of the most important things for dump analysis (and that's what the issue about). So we cannot avoid stack unwinding for unmounted virtual threads.
> > As for heapdump file size, each stack trace adds 21 + 53 * frame_number bytes for 64bit system (uncompressed data)
> > So for 10 frames it adds ~550 bytes, for 20 frames ~1.1KB
> > I'm not sure if stack traces are important for analysis, maybe we it makes sense to add an option to not include them in heap dump (for both platform and virtual threads).
> 
> My concern was with the memory usage of the stack traces. Yes I agree that including all referenced objects in the dump is important. An option just to leave out the stack traces seems like a good idea.

VM_HeapDumper caches stack traces for platform/carrier and mounted virtual threads only.
For unmounted virtual threads ThreadDumper objects are created on the stack (see `VM_HeapDumper::dump_vthread`), so I don't see problems with memory usage even huge number of unmounted vthreads.
I think an option to exclude stack traces from heap dump is a separate task.

> 
> > Hprof spec says nothing about 1:1 relation between threads and stack traces, so theoretically several HPROF_GC_ROOT_THREAD_OBJ subrecords may refer to the same stack trace, but search for identical stack traces may be expensive.
> 
> I was thinking initially that you couldn't do this because each stack has it's own unique set of locals that are referenced, and the locals were part of the stack trace, but they are not. There is instead a HPROF_GC_ROOT_JAVA_FRAME record for each local reference. It does include the ThreadID, and we could probably get away with multiple Thread records referring to the same stack trace.

I think this possible improvement is out of scope for this PR

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16665#issuecomment-1839838068