On Sat, 2 Jul 2022 05:16:22 GMT, Chris Plummer wrote:
>> test/jdk/com/sun/jdi/SuspendAfterDeath.java line 73:
>>
>>> 71:
>>> 72: public class SuspendAfterDeath extends TestScaffold {
>>> 73: private volatile ThreadReference thread;
>>
>> One minor naming suggestion:
>> The name `thread` is
On Sat, 2 Jul 2022 06:21:36 GMT, Chris Plummer wrote:
>> This fixes a bug in the debug agent when there is a request to suspend a
>> virtual thread that has already terminated. The issue was that unless the
>> debug agent was currently under a "suspend all", it would not properly put
>> the vi
> This fixes a bug in the debug agent when there is a request to suspend a
> virtual thread that has already terminated. The issue was that unless the
> debug agent was currently under a "suspend all", it would not properly put
> the virtual thread on the `otherThreads` list, and instead added i
> This fixes a bug in the debug agent when there is a request to suspend a
> virtual thread that has already terminated. The issue was that unless the
> debug agent was currently under a "suspend all", it would not properly put
> the virtual thread on the `otherThreads` list, and instead added i
On Fri, 1 Jul 2022 17:47:51 GMT, Serguei Spitsyn wrote:
> This is fixing the JVM TI GetThreadState issue which returns for terminated
> virtual thread state = 0 instead of 2 (`JVMTI_THREAD_STATE_TERMINATED`). The
> problem was in the function `JvmtiEnvBase::get_threadOop_and_JavaThread`
> whic
On Sat, 2 Jul 2022 03:35:11 GMT, Serguei Spitsyn wrote:
>> This is fixing the JVM TI GetThreadState issue which returns for terminated
>> virtual thread state = 0 instead of 2 (`JVMTI_THREAD_STATE_TERMINATED`). The
>> problem was in the function `JvmtiEnvBase::get_threadOop_and_JavaThread`
>>
On Sat, 2 Jul 2022 05:23:04 GMT, Chris Plummer wrote:
>> test/jdk/com/sun/jdi/TestScaffold.java line 976:
>>
>>> 974: }
>>> 975: });
>>> 976: Thread.currentThread().setName(OLD_MAIN_THREAD_NAME);
>>
>> Just want to understand what is this thread naming is
On Thu, 30 Jun 2022 13:20:22 GMT, Alan Bateman wrote:
> The description of the ThreadStart/End events in the JVM TI spec needs
> rewording to make it clearer when these events are sent for virtual threads
> and when VirtualThreadXXX events are sent instead.
Marked as reviewed by cjplummer (Rev
On Sat, 2 Jul 2022 02:32:09 GMT, Serguei Spitsyn wrote:
>> Chris Plummer has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> provide a slightly more descriptive @summary
>
> test/jdk/com/sun/jdi/SuspendAfterDeath.java line 73:
>
>> 71:
>>
On Sat, 2 Jul 2022 03:22:31 GMT, Serguei Spitsyn wrote:
> Interesting enough that I've found the existing test which already had needed
> coverage: `
> test/hotspot/jtreg/serviceability/jvmti/thread/GetThreadState/thrstat03` But
> this test was adjusted to adopt to incorrect GetThreadState res
On Sat, 2 Jul 2022 03:35:11 GMT, Serguei Spitsyn wrote:
>> This is fixing the JVM TI GetThreadState issue which returns for terminated
>> virtual thread state = 0 instead of 2 (`JVMTI_THREAD_STATE_TERMINATED`). The
>> problem was in the function `JvmtiEnvBase::get_threadOop_and_JavaThread`
>>
> There are only two implementations of these classes (one for windows, and one
> for posix):
>
> - PlatformEvent
> - PlatformParker
> - PlatformMutex
> - PlatformMonitor
> - ThreadCrashProtection
>
> Before this PR, these classes are declared in os_xxx.hpp. This causes
> excessive inclusion of
On Fri, 1 Jul 2022 18:17:35 GMT, Chris Plummer wrote:
>> This fixes a bug in the debug agent when there is a request to suspend a
>> virtual thread that has already terminated. The issue was that unless the
>> debug agent was currently under a "suspend all", it would not properly put
>> the vi
> This is fixing the JVM TI GetThreadState issue which returns for terminated
> virtual thread state = 0 instead of 2 (`JVMTI_THREAD_STATE_TERMINATED`). The
> problem was in the function `JvmtiEnvBase::get_threadOop_and_JavaThread`
> which does a check and reurns JVMTI_ERROR_THREAD_NOT_ALIVE a l
On Sat, 2 Jul 2022 03:10:05 GMT, Serguei Spitsyn wrote:
>> test/hotspot/jtreg/serviceability/jvmti/vthread/SelfSuspendDisablerTest/libSelfSuspendDisablerTest.cpp
>> line 68:
>>
>>> 66: }
>>> 67:
>>> 68: }
>>
>> it might be helpful to add
>>
>> // extern "C"
>>
>> after the brace as it con
On Fri, 1 Jul 2022 19:59:25 GMT, Chris Plummer wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> fix serviceability/jvmti/thread/thrstat03 to except correct GetThreadState
>> result for terminated vthreads
>
> te
On Fri, 1 Jul 2022 18:51:55 GMT, Alan Bateman wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> fix serviceability/jvmti/thread/thrstat03 to except correct GetThreadState
>> result for terminated vthreads
>
> tes
On Fri, 1 Jul 2022 18:53:36 GMT, Alan Bateman wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> fix serviceability/jvmti/thread/thrstat03 to except correct GetThreadState
>> result for terminated vthreads
>
> tes
On Fri, 1 Jul 2022 18:17:35 GMT, Chris Plummer wrote:
>> This fixes a bug in the debug agent when there is a request to suspend a
>> virtual thread that has already terminated. The issue was that unless the
>> debug agent was currently under a "suspend all", it would not properly put
>> the vi
On Fri, 1 Jul 2022 18:17:35 GMT, Chris Plummer wrote:
>> This fixes a bug in the debug agent when there is a request to suspend a
>> virtual thread that has already terminated. The issue was that unless the
>> debug agent was currently under a "suspend all", it would not properly put
>> the vi
On Fri, 1 Jul 2022 21:48:29 GMT, Serguei Spitsyn wrote:
>> This is fixing the JVM TI GetThreadState issue which returns for terminated
>> virtual thread state = 0 instead of 2 (`JVMTI_THREAD_STATE_TERMINATED`). The
>> problem was in the function `JvmtiEnvBase::get_threadOop_and_JavaThread`
>>
On Tue, 28 Jun 2022 20:13:01 GMT, Ioi Lam wrote:
>> There are only two implementations of these classes (one for windows, and
>> one for posix):
>>
>> - PlatformEvent
>> - PlatformParker
>> - PlatformMutex
>> - PlatformMonitor
>> - ThreadCrashProtection
>>
>> Before this PR, these classes are
> This is fixing the JVM TI GetThreadState issue which returns for terminated
> virtual thread state = 0 instead of 2 (`JVMTI_THREAD_STATE_TERMINATED`). The
> problem was in the function `JvmtiEnvBase::get_threadOop_and_JavaThread`
> which does a check and reurns JVMTI_ERROR_THREAD_NOT_ALIVE a l
On Fri, 1 Jul 2022 18:17:35 GMT, Chris Plummer wrote:
>> This fixes a bug in the debug agent when there is a request to suspend a
>> virtual thread that has already terminated. The issue was that unless the
>> debug agent was currently under a "suspend all", it would not properly put
>> the vi
On Fri, 1 Jul 2022 17:47:51 GMT, Serguei Spitsyn wrote:
> This is fixing the JVM TI GetThreadState issue which returns for terminated
> virtual thread state = 0 instead of 2 (`JVMTI_THREAD_STATE_TERMINATED`). The
> problem was in the function `JvmtiEnvBase::get_threadOop_and_JavaThread`
> whic
On Fri, 1 Jul 2022 18:49:52 GMT, Chris Plummer wrote:
> Is there a reason you chose to use "by" instead of "for"?
The specification of these two events have always used "generated by" in the
first sentence of the description so it's just keeping it consistent. The
thread lifecycle events are
On Fri, 1 Jul 2022 17:47:51 GMT, Serguei Spitsyn wrote:
> This is fixing the JVM TI GetThreadState issue which returns for terminated
> virtual thread state = 0 instead of 2 (`JVMTI_THREAD_STATE_TERMINATED`). The
> problem was in the function `JvmtiEnvBase::get_threadOop_and_JavaThread`
> whic
On Fri, 1 Jul 2022 17:47:51 GMT, Serguei Spitsyn wrote:
> This is fixing the JVM TI GetThreadState issue which returns for terminated
> virtual thread state = 0 instead of 2 (`JVMTI_THREAD_STATE_TERMINATED`). The
> problem was in the function `JvmtiEnvBase::get_threadOop_and_JavaThread`
> whic
On Fri, 1 Jul 2022 18:17:35 GMT, Chris Plummer wrote:
>> This fixes a bug in the debug agent when there is a request to suspend a
>> virtual thread that has already terminated. The issue was that unless the
>> debug agent was currently under a "suspend all", it would not properly put
>> the vi
On Thu, 30 Jun 2022 13:20:22 GMT, Alan Bateman wrote:
> The description of the ThreadStart/End events in the JVM TI spec needs
> rewording to make it clearer when these events are sent for virtual threads
> and when VirtualThreadXXX events are sent instead.
src/hotspot/share/prims/jvmti.xml li
On Fri, 1 Jul 2022 12:57:55 GMT, Zhengyu Gu wrote:
>> Currently, jdi only check and process class unloading event when it detects
>> a new GC cycle.
>>
>> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting
>> class events can overlap with GC finish event, that results, s
> This fixes a bug in the debug agent when there is a request to suspend a
> virtual thread that has already terminated. The issue was that unless the
> debug agent was currently under a "suspend all", it would not properly put
> the virtual thread on the `otherThreads` list, and instead added i
This is fixing the JVM TI GetThreadState issue which returns for terminated
virtual thread state = 0 instead of 2 (`JVMTI_THREAD_STATE_TERMINATED`). The
problem was in the function `JvmtiEnvBase::get_threadOop_and_JavaThread` which
does a check and reurns JVMTI_ERROR_THREAD_NOT_ALIVE a little bi
On Thu, 30 Jun 2022 13:20:22 GMT, Alan Bateman wrote:
> The description of the ThreadStart/End events in the JVM TI spec needs
> rewording to make it clearer when these events are sent for virtual threads
> and when VirtualThreadXXX events are sent instead.
Looks good.
Thanks,
Serguei
---
On Fri, 1 Jul 2022 16:12:17 GMT, Daniel D. Daugherty wrote:
> A trivial fix to ProblemList sun/tools/jhsdb/JStackStressTest.java on
> linux-aarch64.
This pull request has now been integrated.
Changeset: 20124ac7
Author:Daniel D. Daugherty
URL:
https://git.openjdk.org/jdk19/commit/
On Fri, 1 Jul 2022 16:16:50 GMT, Kevin Walls wrote:
>> A trivial fix to ProblemList sun/tools/jhsdb/JStackStressTest.java on
>> linux-aarch64.
>
> Marked as reviewed by kevinw (Committer).
@kevinjwalls - Thanks for the fast review!
-
PR: https://git.openjdk.org/jdk19/pull/100
On Fri, 1 Jul 2022 16:13:56 GMT, Brian Burkhalter wrote:
>> A trivial fix to ProblemList sun/tools/jhsdb/JStackStressTest.java on
>> linux-aarch64.
>
> Marked as reviewed by bpb (Reviewer).
@bplb - Thanks for the lightning fast review!
-
PR: https://git.openjdk.org/jdk19/pull/100
On Fri, 1 Jul 2022 16:12:17 GMT, Daniel D. Daugherty wrote:
> A trivial fix to ProblemList sun/tools/jhsdb/JStackStressTest.java on
> linux-aarch64.
Marked as reviewed by kevinw (Committer).
-
PR: https://git.openjdk.org/jdk19/pull/100
On Fri, 1 Jul 2022 16:12:17 GMT, Daniel D. Daugherty wrote:
> A trivial fix to ProblemList sun/tools/jhsdb/JStackStressTest.java on
> linux-aarch64.
Marked as reviewed by bpb (Reviewer).
-
PR: https://git.openjdk.org/jdk19/pull/100
A trivial fix to ProblemList sun/tools/jhsdb/JStackStressTest.java on
linux-aarch64.
-
Commit messages:
- 8289585: ProblemList sun/tools/jhsdb/JStackStressTest.java on linux-aarch64
Changes: https://git.openjdk.org/jdk19/pull/100/files
Webrev: https://webrevs.openjdk.org/?repo=jd
On Thu, 30 Jun 2022 13:20:22 GMT, Alan Bateman wrote:
> The description of the ThreadStart/End events in the JVM TI spec needs
> rewording to make it clearer when these events are sent for virtual threads
> and when VirtualThreadXXX events are sent instead.
Thumbs up.
-
Marked as
On Thu, 30 Jun 2022 18:39:58 GMT, Harold Seigel wrote:
> Please review this small fix to change range constrained JVM runtime options
> from 64 bits to 32 bits. This fix was tested with Mach5 tiers 1-2 on Linux,
> Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.
>
> Thanks, Harold
This
On Fri, 1 Jul 2022 12:28:35 GMT, David Holmes wrote:
>> Harold Seigel has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix copyright date
>
> src/hotspot/share/runtime/perfMemory.cpp line 2:
>
>> 1: /*
>> 2: * Copyright (c) 2001, 2021,
On Thu, 30 Jun 2022 18:39:58 GMT, Harold Seigel wrote:
> Please review this small fix to change range constrained JVM runtime options
> from 64 bits to 32 bits. This fix was tested with Mach5 tiers 1-2 on Linux,
> Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.
>
> Thanks, Harold
Than
> Please review this small fix to change range constrained JVM runtime options
> from 64 bits to 32 bits. This fix was tested with Mach5 tiers 1-2 on Linux,
> Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.
>
> Thanks, Harold
Harold Seigel has updated the pull request incrementally with
On Thu, 30 Jun 2022 14:54:47 GMT, Zhengyu Gu wrote:
>> I just noticed the test is being added to a newly created
>> hotspot/jtreg/serviciability/jdi directory. It should be placed in one of
>> the existing jdi test locations, either nsk/jdi or jdk/com/sun/jdi. I think
>> the latter would be be
> Currently, jdi only check and process class unloading event when it detects a
> new GC cycle.
>
> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting
> class events can overlap with GC finish event, that results, sometimes, it
> only captures partial or even empty unload
On Thu, 30 Jun 2022 18:39:58 GMT, Harold Seigel wrote:
> Please review this small fix to change range constrained JVM runtime options
> from 64 bits to 32 bits. This fix was tested with Mach5 tiers 1-2 on Linux,
> Mac OS, and Windows, and Mach5 tiers 3-5 on Linux x64.
>
> Thanks, Harold
The
On Thu, 30 Jun 2022 13:20:22 GMT, Alan Bateman wrote:
> The description of the ThreadStart/End events in the JVM TI spec needs
> rewording to make it clearer when these events are sent for virtual threads
> and when VirtualThreadXXX events are sent instead.
This seems fine to me.
On Thu, 30 Jun 2022 19:39:17 GMT, Serguei Spitsyn wrote:
>> The description of the ThreadStart/End events in the JVM TI spec needs
>> rewording to make it clearer when these events are sent for virtual threads
>> and when VirtualThreadXXX events are sent instead.
>
> src/hotspot/share/prims/jvm
On Thu, 30 Jun 2022 13:20:22 GMT, Alan Bateman wrote:
> The description of the ThreadStart/End events in the JVM TI spec needs
> rewording to make it clearer when these events are sent for virtual threads
> and when VirtualThreadXXX events are sent instead.
src/hotspot/share/prims/jvmti.xml li
The description of the ThreadStart/End events in the JVM TI spec needs
rewording to make it clearer when these events are sent for virtual threads and
when VirtualThreadXXX events are sent instead.
-
Commit messages:
- Tweak wording
- Initial commit
Changes: https://git.openjdk.o
On Fri, 1 Jul 2022 05:29:43 GMT, Chris Plummer wrote:
>> This fixes a bug in the debug agent when there is a request to suspend a
>> virtual thread that has already terminated. The issue was that unless the
>> debug agent was currently under a "suspend all", it would not properly put
>> the vi
53 matches
Mail list logo
