On Tue, 19 Dec 2023 01:17:10 GMT, David Holmes <[email protected]> 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
