On Mon, 4 Dec 2023 19:14:59 GMT, Chris Plummer <cjplum...@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
