On Mon, 6 Apr 2026 19:55:07 GMT, Chris Plummer <[email protected]> wrote:
>> Leonid Mesnik has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - updated doc for ThreadWrapper
>> - reverted some tests that can't be really run with virtual threads
>
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS201/hs201t002.java
> line 79:
>
>> 77: log.display(">>> starting tested thread");
>> 78: hs201t002Thread wrappedThread = new hs201t002Thread();
>> 79: Thread thread = wrappedThread.getThread();
>
> Is the issue here the resumeThread(thread) call below? Any reason not to just
> pass thread.getThread() to it. It looks like you've done that elsewhere like
> in hs202t001.java
Yes, there are setThread(), suspendThread(), resumeThread() that expects
Thread. So I just added new variable.
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t001.java
> line 75:
>
>> 73: threadWrappers[0].getThread(),
>> 74: threadWrappers[1].getThread()
>> 75: };
>
> Why not just call getThread() when needed rather than setting up this array?
The threads is static variable that accessed from native library. It uses them
as threads.
> test/hotspot/jtreg/vmTestbase/nsk/share/ExtraClassesBuilder.java line 67:
>
>> 65:
>> .addToolArg(dst.toString())
>> 66: .addToolArg("-sourcepath")
>> 67:
>> .addToolArg(Utils.TEST_SRC_PATH)
>
> Why is this needed now?
It is needed to allow redefined classes to use ThreadWrapper. Like for:
test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS202/hs202t001/newclass00/MyThread.java
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/30591#discussion_r3042335851
PR Review Comment: https://git.openjdk.org/jdk/pull/30591#discussion_r3042359734
PR Review Comment: https://git.openjdk.org/jdk/pull/30591#discussion_r3042342054
