RFR: 8308033: The jcmd thread dump related tests should test virtual threads [v2]

Jaikiran Pai jpai at openjdk.org
Thu May 2 04:09:59 UTC 2024


On Wed, 1 May 2024 19:15:17 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address additional problem listed tests in hotspot/jtreg/serviceability
>
> test/jdk/sun/tools/jstack/BasicJStackTest.java line 53:
> 
>> 51:             // print the stacktraces of virtual threads.
>> 52:             throw new SkippedException("skipping test since current thread is a virtual thread");
>> 53:         }
> 
> I wonder if we can rely on the virtual thread always be mounted. If so, we could revisit this test after [JDK-8330846](https://bugs.openjdk.org/browse/JDK-8330846) is implemented.

Hello Chris, if I understand that JBS issue correctly, then by default jstack (and other tools) will start including stacktraces of virtual threads that currently are mounted on a carrier thread (and thus haven't been parked) in the output.

If that's the case, then I think when that JBS issue is implemented we can remove this conditional check and the skipping of the test since the virtual thread would end up appearing in the thread dump because that's the thread which would be currently launching the `jstack` process and waiting (through a `ReentrantLock`'s `Condition` object) for the jstack process to complete.

To revisit this test when JDK-8330846 is implemented, do you want me to file an issue? Or did you mean we should wait doing the changes in this PR until JDK-8330846 is implemented?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19016#discussion_r1587037457


More information about the serviceability-dev mailing list