RFR: 8299426: Heap dump does not contain virtual Thread stack references [v2]
Chris Plummer
cjplummer at openjdk.org
Fri Dec 1 05:46:08 UTC 2023
On Thu, 30 Nov 2023 00:26:25 GMT, Alex Menkov <amenkov at openjdk.org> wrote:
>> The change impelements dumping of unmounted virtual threads data (stack traces and stack references).
>> Unmounted vthreads can be detected only by iterating over the heap, but hprof stack trace records (HPROF_FRAME/HPROF_TRACE) should be written before HPROF_HEAP_DUMP/HPROF_HEAP_DUMP_SEGMENT.
>> HeapDumper supports segment dump (parallel dump to separate files with subsequent file merge outside of safepoint), the fix switches HeapDumper to always use segment dump: 1st segment contains only non-heap data, other segments are used for dumping heap objects. For serial dumping single-threaded dumping is performed, but 2 segments are created anyway.
>> When HeapObjectDumper detects unmounted virtual thread, it writes HPROF_FRAME/HPROF_TRACE records to the 1st segment ("global writer"), and writes thread object (HPROF_GC_ROOT_JAVA_FRAME) and stack references (HPROF_GC_ROOT_JAVA_FRAME/HPROF_GC_ROOT_JNI_LOCAL) to the HeapObjectDumper segment.
>> As parallel dumpers may write HPROF_FRAME/HPROF_TRACE concurrently and VMDumper needs to write non-heap data before heap object dumpers can write virtual threads data, writing to global writer is protected with DumperController::_global_writer_lock.
>>
>> Testing: run tests which perform heap dump (in different scenarios):
>> - test/hotspot/jtreg/serviceability
>> - test/hotspot/jtreg/runtime/ErrorHandling
>> - test/hotspot/jtreg/gc/epsilon
>> - test/jdk/sun/tools/jhsdb
>
> Alex Menkov has updated the pull request incrementally with two additional commits since the last revision:
>
> - feedback
> - prepare_parallel_dum
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.
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.
-------------
PR Review: https://git.openjdk.org/jdk/pull/16665#pullrequestreview-1759060258
More information about the serviceability-dev
mailing list