Thread.sleep has had quite a bit of churn recently to support virtual threads,
add sleep(Duration), a JFR event, and the change the underlying implementation
to support sub-millis precision. I think the changes have settled down now so
we can do some small cleanups that came up in PR discussions
The test has two issues. The first is that it assume that once the VMStart
event has arrived and one "step into" is done, it will be in the main method of
the debuggee. Once there, it determines the debuggee class name by looking at
the classtype of topmost frame. The problems is when using virt
> OpenJDK Colleagues:
>
> Please review this proposed integration of Generational mode for Shenandoah
> GC under https://bugs.openjdk.org/browse/JDK-8307314.
>
> Generational mode of Shenandoah is enabled by adding
> `-XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational` to a
> c
> JdbMethodExitTest.java tries to determine the jdb threadID for the "main"
> thread, and then later use it in jdb commands that require a threadID. It
> does this by first having the debuggee execute the following:
>
> `System.out.println("threadid="+Thread.currentThread().getId());`
>
On Sat, 3 Jun 2023 21:34:16 GMT, Chris Plummer wrote:
>> Normally when a virtual thread wrapper is used to run a test, the main
>> thread is renamed to "old-m-a-i-n" and the new virtual thread that will act
>> as the main thread is named "main". Neither is being done by
>> `ProcessTools.main()
On Fri, 2 Jun 2023 21:30:46 GMT, Chris Plummer wrote:
> Normally when a virtual thread wrapper is used to run a test, the main thread
> is renamed to "old-m-a-i-n" and the new virtual thread that will act as the
> main thread is named "main". Neither is being done by `ProcessTools.main()`.
> T
On Sat, 3 Jun 2023 18:57:55 GMT, Chris Plummer wrote:
> So I think I should close this PR and update the
> [JDK-8309334](https://bugs.openjdk.org/browse/JDK-8309334) PR to remove the 3
> tests that seem to pass with it and don't also need this PR to pass. The 4th
> test `com/sun/jdi/JdbMethodE
On Sun, 4 Jun 2023 09:38:51 GMT, Serguei Spitsyn wrote:
>> The VM option EnableDynamicAgentLoading was added in JDK 9, default true, to
>> allow deployment to choose whether to allow agents to be loaded/started in
>> the VM. The VM option does the right thing for tools using the Attach API
>>
On Sun, 4 Jun 2023 08:26:06 GMT, Serguei Spitsyn wrote:
> The lines 763-764 are to correct the state exactly for passive carrier
> thread, a carrier thread which can't progress until the execution control has
> not been returned from a virtual thread executed on the top. It is never for
> a pl
On Fri, 2 Jun 2023 02:49:25 GMT, Kelvin Nilsen wrote:
>> OpenJDK Colleagues:
>>
>> Please review this proposed integration of Generational mode for Shenandoah
>> GC under https://bugs.openjdk.org/browse/JDK-8307314.
>>
>> Generational mode of Shenandoah is enabled by adding
>> `-XX:+UnlockExp
> The VM option EnableDynamicAgentLoading was added in JDK 9, default true, to
> allow deployment to choose whether to allow agents to be loaded/started in
> the VM. The VM option does the right thing for tools using the Attach API but
> jcmd JVMTI.agent_load was missed. This should be fixed to
On Sun, 4 Jun 2023 08:05:34 GMT, Alan Bateman wrote:
>> When a virtual thread is mounted, the carrier thread should be reported as
>> "waiting" until the virtual thread unmounts. Right now, GetThreadState
>> reports a state based the JavaThread status when it should return
>> JVMTI_THREAD_STAT
On Sat, 3 Jun 2023 10:53:04 GMT, Serguei Spitsyn wrote:
> When a virtual thread is mounted, the carrier thread should be reported as
> "waiting" until the virtual thread unmounts. Right now, GetThreadState
> reports a state based the JavaThread status when it should return
> JVMTI_THREAD_STATE
On Sat, 3 Jun 2023 21:34:16 GMT, Chris Plummer wrote:
>> Normally when a virtual thread wrapper is used to run a test, the main
>> thread is renamed to "old-m-a-i-n" and the new virtual thread that will act
>> as the main thread is named "main". Neither is being done by
>> `ProcessTools.main()
14 matches
Mail list logo