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

Alex Menkov amenkov at openjdk.org
Sat Dec 2 01:51:37 UTC 2023


On Fri, 1 Dec 2023 05:43:41 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> One concern I have is when there is a large number of virtual threads, the dump may take too long and the hprof file gets bloated. My concern mostly comes from the large number of virtual thread stack traces that will be present. Dumping all these hprof records related to unmounted virtual threads could do more harm than good in some instances, and we may want a way for the user to disable it.

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).

> 
> It would be nice if there could be some data sharing between threads with identical stack traces, but I don't see a way to do that with the current hprof spec.

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.

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

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


More information about the hotspot-runtime-dev mailing list