RFR: JDK-8322237: Heap dump contains duplicate thread records for mounted virtual threads

[Alex Menkov]

On Tue, 19 Dec 2023 01:17:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> HeapDumper dumps virtual threads in 2 places:
>> - dumping platform threads (mounted virtual threads are dumped as separate thread object);
>> - dumping heap objects when the object is `java.lang.VirtualThread`.
>> 
>> In the 2nd case mounted virtual threads should be skipped (as they are already dumped with correct stack traces/stack references)
>> Check that a virtual thread is mounted is non-trivial, method from JvmtiEnvBase was used for this.
>> 
>> Testing: tier1..3, heapdump-related tests: open/test/hotspot/jtreg/serviceability,open/test/hotspot/jtreg/runtime/ErrorHandling,open/test/hotspot/jtreg/gc/epsilon,open/test/jdk/sun/tools/jhsdb
>
> src/hotspot/share/services/heapDumper.cpp line 1647:
> 
>> 1645:   static bool is_vthread_mounted(oop vt) {
>> 1646:     return JvmtiEnvBase::get_JavaThread_or_null(vt) != nullptr;
>> 1647:   }
> 
> It doesn't seem appropriate to couple this to the JVMTI code (can this code be present if JVMTI is not part of the build?). Doesn't the VT state give you a good enough approximation of whether it is mounted i.e. RUNNABLE?

Good point. I'll remove dependency on JVMTI.
I don't think approximation would be good here (comparing state to RUNNABLE/PINNED/TIMED_PINNED or comparing carrierThread with null).
It's racy and we have a chance to not dump unmounted vthread or dump mounted vthread twice.
Maybe `is_vthread_mounted` should check if the virtual thread continuation has non-empty chunk.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17134#discussion_r1430893424