On Sat, 2 Dec 2023 01:48:28 GMT, Alex Menkov <amen...@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. > 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. but now I'm not seeing any indications that hprof stacks reference the locals, which seems odd. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16665#issuecomment-1839303561
