Re: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING [v4]
On Thu, 8 Jun 2023 04:29:47 GMT, David Holmes wrote: >>> > A thread carrying a virtual thread can not be in native, blocked, parked, >>> > sleeping or waiting on some object. >> >>>A virtual thread can call native code, be blocked on an object monitor, or >>>waiting on an object monitor. Only parking and sleeping are specialized for >>>virtual threads in the list you gave. >> >> This statement was about a carrier thread (not a `JavaThread` and not a ` >> java.lang.VirtualThread`) when there is a virtual thread executed at the >> top. We are getting state bits with the >> `java_lang_Thread::get_thread_status(thread_oop)` where the `thread_oop` >> belongs to the carrier thread. But you are talking about a virtual thread >> which, of course, can be in almost any state. > > Thanks for clarifying - it gets very confusing as to which "thread" is being > talked about. But if a virtual thread is mounted on this JavaThread then I > thought the carrier thread's thread-oop is supposed to be in a blocked state? It was decided with Alan that it is okay to be in a waiting state. The `JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER` state requires a monitor to be blocked on, so it can be confusing. Alan's comment in the original PR [https://github.com/openjdk/jdk/pull/14298](https://github.com/openjdk/jdk/pull/14298) was: > if the jt is carrying thread_oop and it's okay for the JVMTI state to > reported as WAITING when waiting for something other than Object.wait. - PR Review Comment: https://git.openjdk.org/jdk/pull/14366#discussion_r1222442892
Re: RFR: 8232839: JDI AfterThreadDeathTest.java failed due to "FAILED: Did not get expected IllegalThreadStateException on a StepRequest.enable()"
On Wed, 7 Jun 2023 23:17:18 GMT, Chris Plummer wrote:
> The test waits for a ThreadDeathEvent for "main". Once that arrives, it then
> waits for the next ThreadStartEvent (for any thread). Once it arrives, the
> test tries to create and enable a StepRequest on the "main" thread. Since
> "main" is supposedly dead, the expectation is an IllegalThreadStateException.
> However, it turns out that sometimes the enabling can in fact succeed.
>
> Just because a ThreadDeathEvent has been received for a thread does not mean
> you can no longer do things with the thread like suspend it or enable a
> StepEvent. There is a short delay in the debug agent after sending the
> ThreadDeathEvent before it stops tracking the thread. The thread can still be
> acted upon until then. The JDWP and JDI specs seem to support doing this:
>
>> Notification of a completed thread in the target VM. The notification is
>> generated by the dying thread before it terminates. Because of this timing,
>> it is possible for {@link VirtualMachine#allThreads} to return this thread
>> after this event is received.
>>
>> Note that this event gives no information about the lifetime of the thread
>> object. It may or may not be collected soon depending on what references
>> exist in the target VM.
>
> What this means is that when the test receives some arbitrary
> ThreadStartEvent after the "main" ThreadDeathEvent has been received, the
> test may in fact still be able to enable a StepRequest on the "main" thread,
> causing the test to fail. What seems to trigger the failure is receiving an
> unexpected spurious ThreadStartEvent such as from the Common-Clean thread or
> a carrier thread, although even then it only fails some of the time. In fact
> if I modify the test to enable the StepRequest when it receives the
> ThreadDeathEvent for "main", it still almost always passes, but will fail
> more frequently than it normally does.
>
> It seems if the test always waits for the ThreadStartEvent for
> "DestroyJavaVM", then the "main" thread is truly gone by then and the test
> always passes, so this is how I've chosen to fix the issue.
>
> Tested with tier1, tier2 svc tests, and tier5 svc tests.
It looks good.
Thanks,
Serguei
-
Marked as reviewed by sspitsyn (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/14372#pullrequestreview-1468978228
Re: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING [v4]
On Thu, 8 Jun 2023 03:36:52 GMT, Serguei Spitsyn wrote: >>> A thread carrying a virtual thread can not be in native, blocked, parked, >>> sleeping or waiting on some object. >> >> A virtual thread can call native code, be blocked on an object monitor, or >> waiting on an object monitor. Only parking and sleeping are specialized for >> virtual threads in the list you gave. > >> > A thread carrying a virtual thread can not be in native, blocked, parked, >> > sleeping or waiting on some object. > >>A virtual thread can call native code, be blocked on an object monitor, or >>waiting on an object monitor. Only parking and sleeping are specialized for >>virtual threads in the list you gave. > > This statement was about a carrier thread (not a `JavaThread` and not a ` > java.lang.VirtualThread`) when there is a virtual thread executed at the top. > We are getting state bits with the > `java_lang_Thread::get_thread_status(thread_oop)` where the `thread_oop` > belongs to the carrier thread. But you are talking about a virtual thread > which, of course, can be in almost any state. Thanks for clarifying - it gets very confusing as to which "thread" is being talked about. But if a virtual thread is mounted on this JavaThread then I thought the carrier thread's thread-oop is supposed to be in a blocked state? - PR Review Comment: https://git.openjdk.org/jdk/pull/14366#discussion_r1222437953
Integrated: 8309602: update JVMTI history table for jdk 21
On Wed, 7 Jun 2023 12:32:14 GMT, Serguei Spitsyn wrote: > This is a minor update of the `jvmti.xml` file. > The JVM TI history table needs to be updated to list: > - Virtual threads finalized to be a permanent feature. > - Agent start-up in the live phase now specified to print a warning. > > The JVM TI history table has no normative changes. This update does not need > a CSR. This pull request has now been integrated. Changeset: 5af9d2a0 Author:Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/5af9d2a0ac82ad83dc83461e5b8ce793cc995ad3 Stats: 44 lines in 1 file changed: 0 ins; 10 del; 34 mod 8309602: update JVMTI history table for jdk 21 Reviewed-by: alanb, iris - PR: https://git.openjdk.org/jdk/pull/14352
Re: RFR: 8309602: update JVMTI history table for jdk 21 [v4]
On Thu, 8 Jun 2023 04:01:56 GMT, Serguei Spitsyn wrote: >> This is a minor update of the `jvmti.xml` file. >> The JVM TI history table needs to be updated to list: >> - Virtual threads finalized to be a permanent feature. >> - Agent start-up in the live phase now specified to print a warning. >> >> The JVM TI history table has no normative changes. This update does not need >> a CSR. > > Serguei Spitsyn has updated the pull request incrementally with one > additional commit since the last revision: > > improved formatting in the jvmti.xml history table Alan and Iris, thank you for review! - PR Comment: https://git.openjdk.org/jdk/pull/14352#issuecomment-1581857901
Re: RFR: 8309602: update JVMTI history table for jdk 21 [v4]
> This is a minor update of the `jvmti.xml` file. > The JVM TI history table needs to be updated to list: > - Virtual threads finalized to be a permanent feature. > - Agent start-up in the live phase now specified to print a warning. > > The JVM TI history table has no normative changes. This update does not need > a CSR. Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: improved formatting in the jvmti.xml history table - Changes: - all: https://git.openjdk.org/jdk/pull/14352/files - new: https://git.openjdk.org/jdk/pull/14352/files/11db4f4f..8b0997a2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=14352=03 - incr: https://webrevs.openjdk.org/?repo=jdk=14352=02-03 Stats: 43 lines in 1 file changed: 0 ins; 14 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/14352.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14352/head:pull/14352 PR: https://git.openjdk.org/jdk/pull/14352
Re: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING [v4]
On Thu, 8 Jun 2023 02:07:00 GMT, David Holmes wrote: > > A thread carrying a virtual thread can not be in native, blocked, parked, > > sleeping or waiting on some object. >A virtual thread can call native code, be blocked on an object monitor, or >waiting on an object monitor. Only parking and sleeping are specialized for >virtual threads in the list you gave. This statement was about carrier thread when there is a virtual thread executed at the top. We are getting state bits with the `java_lang_Thread::get_thread_status(thread_oop)` where the `thread_oop` belongs to the carrier thread. But you are talking about a virtual thread which, of course, can be in almost any state. - PR Review Comment: https://git.openjdk.org/jdk/pull/14366#discussion_r1222413499
Re: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING [v4]
On Thu, 8 Jun 2023 01:40:06 GMT, Serguei Spitsyn wrote: >> The INTERRUPTED bit we need has to be returned by the >> `java_lang_Thread::get_thread_status`. >> Not completely sure but the bit jt->is_interrupted(false) can be set for the >> mounted virtual thread. >> The JVMTI InterruptThread calls this function to set interrupt bit for >> non-virtual threads: >> ` java_lang_Thread::set_interrupted(thread_obj, true);` > > Corrected the function `get_thread_state()` to make it more safe. > Only `ALIVE` and `INTERRUPTED` bits are taken from result of > `java_lang_Thread::get_thread_status(thread_oop)`. > A thread carrying a virtual thread can not be in native, blocked, parked, > sleeping or waiting on some object. A virtual thread can call native code, be blocked on an object monitor, or waiting on an object monitor. Only parking and sleeping are specialized for virtual threads in the list you gave. - PR Review Comment: https://git.openjdk.org/jdk/pull/14366#discussion_r1222364495
Re: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING [v4]
On Wed, 7 Jun 2023 23:08:52 GMT, Serguei Spitsyn wrote: >>> A thread carrying a virtual thread can not be in native, blocked, parked, >>> sleeping or waiting on some object. >> >> Actually it can be in native. >> And if I remember correctly synchronized block pins virtual thread, so >> inside synchronized we can get other states > > The INTERRUPTED bit we need has to be returned by the > `java_lang_Thread::get_thread_status`. > Not completely sure but the bit jt->is_interrupted(false) can be set for the > mounted virtual thread. > The JVMTI InterruptThread calls this function to set interrupt bit for > non-virtual threads: > ` java_lang_Thread::set_interrupted(thread_obj, true);` Corrected the function `get_thread_state()` to make it more safe. Only `ALIVE` and `INTERRUPTED` bits are taken from result of `java_lang_Thread::get_thread_status(thread_oop)`. - PR Review Comment: https://git.openjdk.org/jdk/pull/14366#discussion_r1222352148
Re: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING [v6]
> This is REDO the fix of > [JDK-8307153](https://bugs.openjdk.org/browse/JDK-8307153). > The last update of the fix in the review cycle was incorrect and incorrectly > tested, so the issue has not been noticed. It is why the fix was backed out. > The issue is that the SUSPEND bit was missed in the JVMTI thread state of > platform/carrier threads carrying virtual threads > (see`JvmtiEnvBase::get_thread_state` function). > > The first push/patch is the original fix of JDK-8307153. > The fix of the SUSPEND bit issue will be in the incremental update. > It is to simplify the review. > > Testing: > - TBD: mach5 tiers 1-5 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: corrected the function get_thread_state for safety - Changes: - all: https://git.openjdk.org/jdk/pull/14366/files - new: https://git.openjdk.org/jdk/pull/14366/files/8f26e277..5fd74f39 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=14366=05 - incr: https://webrevs.openjdk.org/?repo=jdk=14366=04-05 Stats: 13 lines in 1 file changed: 10 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14366.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14366/head:pull/14366 PR: https://git.openjdk.org/jdk/pull/14366
RFR: 8232839: JDI AfterThreadDeathTest.java failed due to "FAILED: Did not get expected IllegalThreadStateException on a StepRequest.enable()"
The test waits for a ThreadDeathEvent for "main". Once that arrives, it then
waits for the next ThreadStartEvent (for any thread). Once it arrives, the test
tries to create and enable a StepRequest on the "main" thread. Since "main" is
supposedly dead, the expectation is an IllegalThreadStateException. However, it
turns out that sometimes the enabling can in fact succeed.
Just because a ThreadDeathEvent has been received for a thread does not mean
you can no longer do things with the thread like suspend it or enable a
StepEvent. There is a short delay in the debug agent after sending the
ThreadDeathEvent before it stops tracking the thread. The thread can still be
acted upon until then. The JDWP and JDI specs seem to support doing this:
> Notification of a completed thread in the target VM. The notification is
> generated by the dying thread before it terminates. Because of this timing,
> it is possible for {@link VirtualMachine#allThreads} to return this thread
> after this event is received.
>
> Note that this event gives no information about the lifetime of the thread
> object. It may or may not be collected soon depending on what references
> exist in the target VM.
What this means is that when the test receives some arbitrary ThreadStartEvent
after the "main" ThreadDeathEvent has been received, the test may in fact still
be able to enable a StepRequest on the "main" thread, causing the test to fail.
What seems to trigger the failure is receiving an unexpected spurious
ThreadStartEvent such as from the Common-Clean thread or a carrier thread,
although even then it only fails some of the time. In fact if I modify the test
to enable the StepRequest when it receives the ThreadDeathEvent for "main", it
still almost always passes, but will fail more frequently than it normally does.
It seems if the test always waits for the ThreadStartEvent for "DestroyJavaVM",
then the "main" thread is truly gone by then and the test always passes, so
this is how I've chosen to fix the issue.
-
Commit messages:
- Fix 8232839
Changes: https://git.openjdk.org/jdk/pull/14372/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=14372=00
Issue: https://bugs.openjdk.org/browse/JDK-8232839
Stats: 24 lines in 2 files changed: 11 ins; 3 del; 10 mod
Patch: https://git.openjdk.org/jdk/pull/14372.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/14372/head:pull/14372
PR: https://git.openjdk.org/jdk/pull/14372
Re: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING [v4]
On Wed, 7 Jun 2023 22:48:47 GMT, Alex Menkov wrote:
>> Do you need to check jt->is_interrupted(false) and set INTERRUPTED bit?
>> It looks like java_lang_Thread::get_thread_status(thread_oop) can only
>> return RUNNABLE in the case and we clear it, so the call is not needed:
>>
>> if (is_thread_carrying_vthread(jt, thread_oop)) {
>> jint state = JVMTI_THREAD_STATE_WAITING |
>> JVMTI_THREAD_STATE_WAITING_INDEFINITELY;
>> if (jt->is_carrier_thread_suspended()) {
>> state |= JVMTI_THREAD_STATE_SUSPENDED;
>> }
>> if (jt->is_interrupted(false)) {
>> state |= JVMTI_THREAD_STATE_INTERRUPTED;
>> }
>> return state;
>> } else ...
>
>> A thread carrying a virtual thread can not be in native, blocked, parked,
>> sleeping or waiting on some object.
>
> Actually it can be in native.
> And if I remember correctly synchronized block pins virtual thread, so inside
> synchronized we can get other states
The INTERRUPTED bit we need has to be returned by the
`java_lang_Thread::get_thread_status`.
Not completely sure but the bit jt->is_interrupted(false) can be set for the
mounted virtual thread.
The JVMTI InterruptThread calls this function to set interrupt bit for
non-virtual threads:
` java_lang_Thread::set_interrupted(thread_obj, true);`
-
PR Review Comment: https://git.openjdk.org/jdk/pull/14366#discussion_r168031
Re: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING [v4]
On Wed, 7 Jun 2023 22:42:49 GMT, Alex Menkov wrote:
>> Good concern.
>> There are two bits (and the related RUNNABLE bit) that we care in this
>> sub-tree of state bits: `SUSPENDED` and `INTERRUPTED`. This update clones
>> these two bits. The RUNNABLE bit must be cleared.
>> A thread carrying a virtual thread can not be in native, blocked, parked,
>> sleeping or waiting on some object.
>> The state returned by the `get_thread_state_base` is based on the call:
>> `state = (jint)java_lang_Thread::get_thread_status(thread_oop);`
>> and addition of the derived from JavaThread bits: `SUSPENDED`, `INTERRUPTED`
>> and `IN_NATIVE`.
>> The three bits derived from the JavaThread are not relevant.
>> This call has to be made directly:
>> ` state = (jint)java_lang_Thread::get_thread_status(thread_oop);`
>> The SUSPEND bit has to be based on the call:
>> `jt->is_carrier_thread_suspended();`
>>
>> The function `get_thread_state` will look as below:
>>
>> if (is_thread_carrying_vthread(jt, thread_oop)) {
>> jint state = (jint)java_lang_Thread::get_thread_status(thread_oop);
>> if (jt->is_carrier_thread_suspended()) {
>> state |= JVMTI_THREAD_STATE_SUSPENDED;
>> }
>> // It's okay for the JVMTI state to be reported as WAITING when waiting
>> // for something other than an Object.wait. So, we treat a thread
>> carrying
>> // a virtual thread as waiting indefinitely which is not runnable.
>> // It is why the RUNNABLE bit is cleared and the WAITING bits are added.
>> state &= ~JVMTI_THREAD_STATE_RUNNABLE;
>> state |= JVMTI_THREAD_STATE_WAITING |
>> JVMTI_THREAD_STATE_WAITING_INDEFINITELY;
>> return state;
>> } else {
>> return get_thread_state_base(thread_oop, jt);
>> }
>
> Do you need to check jt->is_interrupted(false) and set INTERRUPTED bit?
> It looks like java_lang_Thread::get_thread_status(thread_oop) can only return
> RUNNABLE in the case and we clear it, so the call is not needed:
>
> if (is_thread_carrying_vthread(jt, thread_oop)) {
> jint state = JVMTI_THREAD_STATE_WAITING |
> JVMTI_THREAD_STATE_WAITING_INDEFINITELY;
> if (jt->is_carrier_thread_suspended()) {
> state |= JVMTI_THREAD_STATE_SUSPENDED;
> }
> if (jt->is_interrupted(false)) {
> state |= JVMTI_THREAD_STATE_INTERRUPTED;
> }
> return state;
> } else ...
> A thread carrying a virtual thread can not be in native, blocked, parked,
> sleeping or waiting on some object.
Actually it can be in native.
And if I remember correctly synchronized block pins virtual thread, so inside
synchronized we can get other states
-
PR Review Comment: https://git.openjdk.org/jdk/pull/14366#discussion_r155498
Re: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING [v4]
On Wed, 7 Jun 2023 21:52:33 GMT, Serguei Spitsyn wrote:
>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 765:
>>
>>> 763: if (is_thread_carrying_vthread(jt, thread_oop)) {
>>> 764: state &= ~JVMTI_THREAD_STATE_RUNNABLE;
>>> 765: state |= JVMTI_THREAD_STATE_WAITING |
>>> JVMTI_THREAD_STATE_WAITING_INDEFINITELY;
>>
>> This does not look correct.
>> GetThreadState spec provides hierarchical set of questions to interpret
>> thread state value.
>> JVMTI_THREAD_STATE_ALIVE | JVMTI_THREAD_STATE_WAITING |
>> JVMTI_THREAD_STATE_WAITING_INDEFINITELY is only one branch and I'd expect
>> all other bits are not set for this state.
>> Need to decide what do we want to report as carrier thread state for all
>> possible values returned by get_thread_state_base().
>
> Good concern.
> There are two bits (and the related RUNNABLE bit) that we care in this
> sub-tree of state bits: `SUSPENDED` and `INTERRUPTED`. This update clones
> these two bits. The RUNNABLE bit must be cleared.
> A thread carrying a virtual thread can not be in native, blocked, parked,
> sleeping or waiting on some object.
> The state returned by the `get_thread_state_base` is based on the call:
> `state = (jint)java_lang_Thread::get_thread_status(thread_oop);`
> and addition of the derived from JavaThread bits: `SUSPENDED`, `INTERRUPTED`
> and `IN_NATIVE`.
> The three bits derived from the JavaThread are not relevant.
> This call has to be made directly:
> ` state = (jint)java_lang_Thread::get_thread_status(thread_oop);`
> The SUSPEND bit has to be based on the call:
> `jt->is_carrier_thread_suspended();`
>
> The function `get_thread_state` will look as below:
>
> if (is_thread_carrying_vthread(jt, thread_oop)) {
> jint state = (jint)java_lang_Thread::get_thread_status(thread_oop);
> if (jt->is_carrier_thread_suspended()) {
> state |= JVMTI_THREAD_STATE_SUSPENDED;
> }
> // It's okay for the JVMTI state to be reported as WAITING when waiting
> // for something other than an Object.wait. So, we treat a thread carrying
> // a virtual thread as waiting indefinitely which is not runnable.
> // It is why the RUNNABLE bit is cleared and the WAITING bits are added.
> state &= ~JVMTI_THREAD_STATE_RUNNABLE;
> state |= JVMTI_THREAD_STATE_WAITING |
> JVMTI_THREAD_STATE_WAITING_INDEFINITELY;
> return state;
> } else {
> return get_thread_state_base(thread_oop, jt);
> }
Do you need to check jt->is_interrupted(false) and set INTERRUPTED bit?
It looks like java_lang_Thread::get_thread_status(thread_oop) can only return
RUNNABLE in the case and we clear it, so the call is not needed:
if (is_thread_carrying_vthread(jt, thread_oop)) {
jint state = JVMTI_THREAD_STATE_WAITING |
JVMTI_THREAD_STATE_WAITING_INDEFINITELY;
if (jt->is_carrier_thread_suspended()) {
state |= JVMTI_THREAD_STATE_SUSPENDED;
}
if (jt->is_interrupted(false)) {
state |= JVMTI_THREAD_STATE_INTERRUPTED;
}
return state;
} else ...
-
PR Review Comment: https://git.openjdk.org/jdk/pull/14366#discussion_r152628
Re: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING [v5]
On Wed, 7 Jun 2023 21:22:41 GMT, Serguei Spitsyn wrote: >> This is REDO the fix of >> [JDK-8307153](https://bugs.openjdk.org/browse/JDK-8307153). >> The last update of the fix in the review cycle was incorrect and incorrectly >> tested, so the issue has not been noticed. It is why the fix was backed out. >> The issue is that the SUSPEND bit was missed in the JVMTI thread state of >> platform/carrier threads carrying virtual threads >> (see`JvmtiEnvBase::get_thread_state` function). >> >> The first push/patch is the original fix of JDK-8307153. >> The fix of the SUSPEND bit issue will be in the incremental update. >> It is to simplify the review. >> >> Testing: >> - TBD: mach5 tiers 1-5 > > Serguei Spitsyn has updated the pull request incrementally with one > additional commit since the last revision: > > review: added/adjusted some comments Marked as reviewed by cjplummer (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/14366#pullrequestreview-1468678777
Re: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING [v4]
On Wed, 7 Jun 2023 21:12:24 GMT, Alex Menkov wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> fix trailing space in jvmtiEnvBase.cpp
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 765:
>
>> 763: if (is_thread_carrying_vthread(jt, thread_oop)) {
>> 764: state &= ~JVMTI_THREAD_STATE_RUNNABLE;
>> 765: state |= JVMTI_THREAD_STATE_WAITING |
>> JVMTI_THREAD_STATE_WAITING_INDEFINITELY;
>
> This does not look correct.
> GetThreadState spec provides hierarchical set of questions to interpret
> thread state value.
> JVMTI_THREAD_STATE_ALIVE | JVMTI_THREAD_STATE_WAITING |
> JVMTI_THREAD_STATE_WAITING_INDEFINITELY is only one branch and I'd expect all
> other bits are not set for this state.
> Need to decide what do we want to report as carrier thread state for all
> possible values returned by get_thread_state_base().
Good concern.
There are two bits (and the related RUNNABLE bit) that we care in this sub-tree
of state bits: `SUSPENDED` and `INTERRUPTED`. This update clones these two
bits. The RUNNABLE bit must be cleared.
A thread carrying a virtual thread can not be in native, blocked, parked,
sleeping or waiting on some object.
The state returned by the `get_thread_state_base` is based on the call:
`state = (jint)java_lang_Thread::get_thread_status(thread_oop);`
and addition of the derived from JavaThread bits: `SUSPENDED`, `INTERRUPTED`
and `IN_NATIVE`.
The three bit derived from the JavaThread are not relevant.
This call has to be made directly:
` state = (jint)java_lang_Thread::get_thread_status(thread_oop);`
The SUSPEND bit has to be based on the call:
`jt->is_carrier_thread_suspended();`
-
PR Review Comment: https://git.openjdk.org/jdk/pull/14366#discussion_r112064
Re: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING [v4]
On Wed, 7 Jun 2023 20:10:24 GMT, Chris Plummer wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> fix trailing space in jvmtiEnvBase.cpp
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 765:
>
>> 763: if (is_thread_carrying_vthread(jt, thread_oop)) {
>> 764: state &= ~JVMTI_THREAD_STATE_RUNNABLE;
>> 765: state |= JVMTI_THREAD_STATE_WAITING |
>> JVMTI_THREAD_STATE_WAITING_INDEFINITELY;
>
> How about a comment here:
>
> "Clear RUNNABLE state and add WAITING state because..."
Thanks. Added comment.
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1739:
>
>> 1737: "sanity check");
>> 1738:
>> 1739: // An attempt to handshake-suspend a thread carrying virtual thread
>> will result in
>
> Suggestion:
>
> // An attempt to handshake-suspend a thread carrying a virtual thread will
> result in
Thanks. Updated now.
> src/hotspot/share/prims/jvmtiEnvBase.hpp line 99:
>
>> 97: static bool is_in_thread_list(jint count, const jthread* list, oop
>> jt_oop);
>> 98:
>> 99: // check if thread_oop represents a thread carrying virtual thread
>
> Suggestion:
>
> // check if thread_oop represents a thread carrying a virtual thread
Thanks. Updated now.
> src/hotspot/share/prims/jvmtiEnvBase.hpp line 183:
>
>> 181:
>> 182: // Return true if the thread identified with a pair is
>> current.
>> 183: // A thread carrying virtual thread is not treated as current.
>
> Suggestion:
>
> // A thread carrying a virtual thread is not treated as current.
Thanks. Updated now.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/14366#discussion_r1222185513
PR Review Comment: https://git.openjdk.org/jdk/pull/14366#discussion_r1222185817
PR Review Comment: https://git.openjdk.org/jdk/pull/14366#discussion_r1222185985
PR Review Comment: https://git.openjdk.org/jdk/pull/14366#discussion_r1222186135
Re: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING [v4]
On Wed, 7 Jun 2023 20:05:45 GMT, Serguei Spitsyn wrote:
>> This is REDO the fix of
>> [JDK-8307153](https://bugs.openjdk.org/browse/JDK-8307153).
>> The last update of the fix in the review cycle was incorrect and incorrectly
>> tested, so the issue has not been noticed. It is why the fix was backed out.
>> The issue is that the SUSPEND bit was missed in the JVMTI thread state of
>> platform/carrier threads carrying virtual threads
>> (see`JvmtiEnvBase::get_thread_state` function).
>>
>> The first push/patch is the original fix of JDK-8307153.
>> The fix of the SUSPEND bit issue will be in the incremental update.
>> It is to simplify the review.
>>
>> Testing:
>> - TBD: mach5 tiers 1-5
>
> Serguei Spitsyn has updated the pull request incrementally with one
> additional commit since the last revision:
>
> fix trailing space in jvmtiEnvBase.cpp
src/hotspot/share/prims/jvmtiEnvBase.cpp line 765:
> 763: if (is_thread_carrying_vthread(jt, thread_oop)) {
> 764: state &= ~JVMTI_THREAD_STATE_RUNNABLE;
> 765: state |= JVMTI_THREAD_STATE_WAITING |
> JVMTI_THREAD_STATE_WAITING_INDEFINITELY;
This does not look correct.
GetThreadState spec provides hierarchical set of questions to interpret thread
state value.
JVMTI_THREAD_STATE_ALIVE | JVMTI_THREAD_STATE_WAITING |
JVMTI_THREAD_STATE_WAITING_INDEFINITELY is only one branch and I'd expect all
other bits are not set for this state.
Need to decide what do we want to report as carrier thread state for all
possible values returned by get_thread_state_base().
-
PR Review Comment: https://git.openjdk.org/jdk/pull/14366#discussion_r1222182733
Re: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING [v5]
> This is REDO the fix of > [JDK-8307153](https://bugs.openjdk.org/browse/JDK-8307153). > The last update of the fix in the review cycle was incorrect and incorrectly > tested, so the issue has not been noticed. It is why the fix was backed out. > The issue is that the SUSPEND bit was missed in the JVMTI thread state of > platform/carrier threads carrying virtual threads > (see`JvmtiEnvBase::get_thread_state` function). > > The first push/patch is the original fix of JDK-8307153. > The fix of the SUSPEND bit issue will be in the incremental update. > It is to simplify the review. > > Testing: > - TBD: mach5 tiers 1-5 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: added/adjusted some comments - Changes: - all: https://git.openjdk.org/jdk/pull/14366/files - new: https://git.openjdk.org/jdk/pull/14366/files/4defcf2e..8f26e277 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=14366=04 - incr: https://webrevs.openjdk.org/?repo=jdk=14366=03-04 Stats: 7 lines in 2 files changed: 4 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/14366.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14366/head:pull/14366 PR: https://git.openjdk.org/jdk/pull/14366
Withdrawn: JDK-8307314: Implementation: Generational Shenandoah (Experimental)
On Fri, 26 May 2023 20:46:29 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:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational` to a > command line that already specifies ` -XX:+UseShenandoahGC`. The > implementation automatically adjusts the sizes of old generation and young > generation to efficiently utilize the entire heap capacity. Generational > mode of Shenandoah resembles G1 in the following regards: > > 1. Old-generation marking runs concurrently during the time that multiple > young generation collections run to completion. > 2. After old-generation marking completes, we perform a sequence of mixed > collections. Each mixed collection combines collection of young generation > with evacuation of a portion of the old-generation regions identified for > collection based on old-generation marking information. > 3. Unlike G1, young-generation collections and evacuations are entirely > concurrent, as with single-generation Shenandoah. > 4. As with single-generation Shenandoah, there is no explicit notion of eden > and survivor space within the young generation. In practice, regions that > were most recently allocated tend to have large amounts of garbage and these > regions tend to be collected with very little effort. Young-generation > objects that survive garbage collection tend to accumulate in regions that > hold survivor objects. These regions tend to have smaller amounts of > garbage, and are less likely to be collected. If they survive a sufficient > number of young-generation collections, the “survivor” regions are promoted > into the old generation. > > We expect to refine heuristics as we gain experience with more production > workloads. In the future, we plan to remove the “experimental” qualifier > from generational mode, at which time we expect that generational mode will > become the default mode for Shenandoah. > > **Testing**: We continuously run jtreg tiers 1-4 + hotspot_gc_shenandoah, > gcstress, jck compiler, jck runtime, Dacapo, SpecJBB, SpecVM, Extremem, > HyperAlloc, and multiple AWS production workload simulators. We test on Linux > x64 and aarch64, Alpine x64 and aarch64, macOS x64 and aarch64, and Windows > x64. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/14185
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v17]
On Wed, 7 Jun 2023 18:21:43 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:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational` to a >> command line that already specifies ` -XX:+UseShenandoahGC`. The >> implementation automatically adjusts the sizes of old generation and young >> generation to efficiently utilize the entire heap capacity. Generational >> mode of Shenandoah resembles G1 in the following regards: >> >> 1. Old-generation marking runs concurrently during the time that multiple >> young generation collections run to completion. >> 2. After old-generation marking completes, we perform a sequence of mixed >> collections. Each mixed collection combines collection of young generation >> with evacuation of a portion of the old-generation regions identified for >> collection based on old-generation marking information. >> 3. Unlike G1, young-generation collections and evacuations are entirely >> concurrent, as with single-generation Shenandoah. >> 4. As with single-generation Shenandoah, there is no explicit notion of eden >> and survivor space within the young generation. In practice, regions that >> were most recently allocated tend to have large amounts of garbage and these >> regions tend to be collected with very little effort. Young-generation >> objects that survive garbage collection tend to accumulate in regions that >> hold survivor objects. These regions tend to have smaller amounts of >> garbage, and are less likely to be collected. If they survive a sufficient >> number of young-generation collections, the “survivor” regions are promoted >> into the old generation. >> >> We expect to refine heuristics as we gain experience with more production >> workloads. In the future, we plan to remove the “experimental” qualifier >> from generational mode, at which time we expect that generational mode will >> become the default mode for Shenandoah. >> >> **Testing**: We continuously run jtreg tiers 1-4 + hotspot_gc_shenandoah, >> gcstress, jck compiler, jck runtime, Dacapo, SpecJBB, SpecVM, Extremem, >> HyperAlloc, and multiple AWS production workload simulators. We test on >> Linux x64 and aarch64, Alpine x64 and aarch64, macOS x64 and aarch64, and >> Windows x64. > > Kelvin Nilsen has updated the pull request incrementally with one additional > commit since the last revision: > > Fix budgeting assertion to allow equal or greater than We would like to thank everyone who has taken time to review and provide feedback on our pull request. Given the risks identified during the review process and the lack of time available to perform the thorough review that such a large contribution of code requires, we have decided to close this PR at the current time. We will seek to target JDK 22. - PR Comment: https://git.openjdk.org/jdk/pull/14185#issuecomment-1581509386
Re: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING [v4]
On Wed, 7 Jun 2023 20:05:45 GMT, Serguei Spitsyn wrote:
>> This is REDO the fix of
>> [JDK-8307153](https://bugs.openjdk.org/browse/JDK-8307153).
>> The last update of the fix in the review cycle was incorrect and incorrectly
>> tested, so the issue has not been noticed. It is why the fix was backed out.
>> The issue is that the SUSPEND bit was missed in the JVMTI thread state of
>> platform/carrier threads carrying virtual threads
>> (see`JvmtiEnvBase::get_thread_state` function).
>>
>> The first push/patch is the original fix of JDK-8307153.
>> The fix of the SUSPEND bit issue will be in the incremental update.
>> It is to simplify the review.
>>
>> Testing:
>> - TBD: mach5 tiers 1-5
>
> Serguei Spitsyn has updated the pull request incrementally with one
> additional commit since the last revision:
>
> fix trailing space in jvmtiEnvBase.cpp
Changes requested by cjplummer (Reviewer).
src/hotspot/share/prims/jvmtiEnvBase.cpp line 765:
> 763: if (is_thread_carrying_vthread(jt, thread_oop)) {
> 764: state &= ~JVMTI_THREAD_STATE_RUNNABLE;
> 765: state |= JVMTI_THREAD_STATE_WAITING |
> JVMTI_THREAD_STATE_WAITING_INDEFINITELY;
How about a comment here:
"Clear RUNNABLE state and add WAITING state because..."
src/hotspot/share/prims/jvmtiEnvBase.cpp line 1739:
> 1737: "sanity check");
> 1738:
> 1739: // An attempt to handshake-suspend a thread carrying virtual thread
> will result in
Suggestion:
// An attempt to handshake-suspend a thread carrying a virtual thread will
result in
src/hotspot/share/prims/jvmtiEnvBase.hpp line 99:
> 97: static bool is_in_thread_list(jint count, const jthread* list, oop
> jt_oop);
> 98:
> 99: // check if thread_oop represents a thread carrying virtual thread
Suggestion:
// check if thread_oop represents a thread carrying a virtual thread
src/hotspot/share/prims/jvmtiEnvBase.hpp line 183:
> 181:
> 182: // Return true if the thread identified with a pair is
> current.
> 183: // A thread carrying virtual thread is not treated as current.
Suggestion:
// A thread carrying a virtual thread is not treated as current.
-
PR Review: https://git.openjdk.org/jdk/pull/14366#pullrequestreview-1468479443
PR Review Comment: https://git.openjdk.org/jdk/pull/14366#discussion_r1222104282
PR Review Comment: https://git.openjdk.org/jdk/pull/14366#discussion_r1222104787
PR Review Comment: https://git.openjdk.org/jdk/pull/14366#discussion_r1222105165
PR Review Comment: https://git.openjdk.org/jdk/pull/14366#discussion_r1222105551
Re: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING [v4]
> This is REDO the fix of > [JDK-8307153](https://bugs.openjdk.org/browse/JDK-8307153). > The last update of the fix in the review cycle was incorrect and incorrectly > tested, so the issue has not been noticed. It is why the fix was backed out. > The issue is that the SUSPEND bit was missed in the JVMTI thread state of > platform/carrier threads carrying virtual threads > (see`JvmtiEnvBase::get_thread_state` function). > > The first push/patch is the original fix of JDK-8307153. > The fix of the SUSPEND bit issue will be in the incremental update. > It is to simplify the review. > > Testing: > - TBD: mach5 tiers 1-5 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: fix trailing space in jvmtiEnvBase.cpp - Changes: - all: https://git.openjdk.org/jdk/pull/14366/files - new: https://git.openjdk.org/jdk/pull/14366/files/094b5f28..4defcf2e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=14366=03 - incr: https://webrevs.openjdk.org/?repo=jdk=14366=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14366.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14366/head:pull/14366 PR: https://git.openjdk.org/jdk/pull/14366
Re: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING [v3]
> This is REDO the fix of > [JDK-8307153](https://bugs.openjdk.org/browse/JDK-8307153). > The last update of the fix in the review cycle was incorrect and incorrectly > tested, so the issue has not been noticed. It is why the fix was backed out. > The issue is that the SUSPEND bit was missed in the JVMTI thread state of > platform/carrier threads carrying virtual threads > (see`JvmtiEnvBase::get_thread_state` function). > > The first push/patch is the original fix of JDK-8307153. > The fix of the SUSPEND bit issue will be in the incremental update. > It is to simplify the review. > > Testing: > - TBD: mach5 tiers 1-5 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: cleanup in comments: replace confusing term: passive carrier thread - Changes: - all: https://git.openjdk.org/jdk/pull/14366/files - new: https://git.openjdk.org/jdk/pull/14366/files/29adb0af..094b5f28 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=14366=02 - incr: https://webrevs.openjdk.org/?repo=jdk=14366=01-02 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/14366.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14366/head:pull/14366 PR: https://git.openjdk.org/jdk/pull/14366
Re: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING [v2]
> This is REDO the fix of > [JDK-8307153](https://bugs.openjdk.org/browse/JDK-8307153). > The last update of the fix in the review cycle was incorrect and incorrectly > tested, so the issue has not been noticed. It is why the fix was backed out. > The issue is that the SUSPEND bit was missed in the JVMTI thread state of > platform/carrier threads carrying virtual threads > (see`JvmtiEnvBase::get_thread_state` function). > > The first push/patch is the original fix of JDK-8307153. > The fix of the SUSPEND bit issue will be in the incremental update. > It is to simplify the review. > > Testing: > - TBD: mach5 tiers 1-5 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: fixed the SUSPEND bit issue in JVMTI thread state of carrier threads - Changes: - all: https://git.openjdk.org/jdk/pull/14366/files - new: https://git.openjdk.org/jdk/pull/14366/files/00f51d34..29adb0af Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=14366=01 - incr: https://webrevs.openjdk.org/?repo=jdk=14366=00-01 Stats: 5 lines in 1 file changed: 0 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/14366.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14366/head:pull/14366 PR: https://git.openjdk.org/jdk/pull/14366
RFR: 8309612: [R[REDO] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING
This is REDO the fix of [JDK-8307153](https://bugs.openjdk.org/browse/JDK-8307153). The last update of the fix in the review cycle was incorrect and incorrectly tested, so the issue has not been noticed. It is why the fix was backed out. The issue is that the SUSPEND bit was missed in the JVMTI thread state of platform/carrier threads carrying virtual threads (see`JvmtiEnvBase::get_thread_state` function). The first push/patch is the original fix of JDK-8307153. The fix of the SUSPEND bit issue will be in the incremental update. It is to simplify the review. Testing: - TBD: mach5 tiers 1-5 - Commit messages: - 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING Changes: https://git.openjdk.org/jdk/pull/14366/files Webrev: https://webrevs.openjdk.org/?repo=jdk=14366=00 Issue: https://bugs.openjdk.org/browse/JDK-8309612 Stats: 82 lines in 4 files changed: 65 ins; 0 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/14366.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14366/head:pull/14366 PR: https://git.openjdk.org/jdk/pull/14366
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v16]
On Wed, 7 Jun 2023 16:51:38 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:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational` to a >> command line that already specifies ` -XX:+UseShenandoahGC`. The >> implementation automatically adjusts the sizes of old generation and young >> generation to efficiently utilize the entire heap capacity. Generational >> mode of Shenandoah resembles G1 in the following regards: >> >> 1. Old-generation marking runs concurrently during the time that multiple >> young generation collections run to completion. >> 2. After old-generation marking completes, we perform a sequence of mixed >> collections. Each mixed collection combines collection of young generation >> with evacuation of a portion of the old-generation regions identified for >> collection based on old-generation marking information. >> 3. Unlike G1, young-generation collections and evacuations are entirely >> concurrent, as with single-generation Shenandoah. >> 4. As with single-generation Shenandoah, there is no explicit notion of eden >> and survivor space within the young generation. In practice, regions that >> were most recently allocated tend to have large amounts of garbage and these >> regions tend to be collected with very little effort. Young-generation >> objects that survive garbage collection tend to accumulate in regions that >> hold survivor objects. These regions tend to have smaller amounts of >> garbage, and are less likely to be collected. If they survive a sufficient >> number of young-generation collections, the “survivor” regions are promoted >> into the old generation. >> >> We expect to refine heuristics as we gain experience with more production >> workloads. In the future, we plan to remove the “experimental” qualifier >> from generational mode, at which time we expect that generational mode will >> become the default mode for Shenandoah. >> >> **Testing**: We continuously run jtreg tiers 1-4 + hotspot_gc_shenandoah, >> gcstress, jck compiler, jck runtime, Dacapo, SpecJBB, SpecVM, Extremem, >> HyperAlloc, and multiple AWS production workload simulators. We test on >> Linux x64 and aarch64, Alpine x64 and aarch64, macOS x64 and aarch64, and >> Windows x64. > > Kelvin Nilsen has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains 305 commits: > > - Merge branch 'master' of https://git.openjdk.org/jdk into > merge-generational-shenandoah > - Simplify test logic, fail if name of Shenandoah young gen pool changes (#3) > > - Remove a few more unneeded copyright notices > - Remove more extraneous copyright notices > - JDK-8309322: [GenShen] TestAllocOutOfMemory#large failed > >When generational Shenandoah is used, there may be an additional >alignment related heap size adjustment that the test should be cognizant >of. Such alignment might also happen in the non-generational case, but >in this case the specific size used in the test was affected on machines >with larger than usual os page size settings. > >The alignment related adjustment would have affected all generational >collectors (except perhaps Gen Z). In the future, we might try and relax >this alignment constraint.alignment. > - Remove one more extraneous Amazon copyright > - Update copyright notices > - Improve efficiency of card-size alignment calculations > - Exit during initialization on unsupported platforms > - Remove an inappropriate copyright notice > - ... and 295 more: https://git.openjdk.org/jdk/compare/33bb64f2...612072a4 I won't be able to give reasonable input here in the short time left before RDP1. Nor am I the most qualified to do so. Just wanted to re-iterate that I see this rushed review with worry. Nothing I have not said already, and of course, it does not diminish the massive effort behind this JEP. Process-wise, when talking about Lilliput integration we touched on the idea of moving RDP1 down to a sooner date. I still think this makes sense. - PR Comment: https://git.openjdk.org/jdk/pull/14185#issuecomment-1581244415
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v12]
On Wed, 7 Jun 2023 14:06:31 GMT, Kelvin Nilsen wrote: > Hi Thomas, > > Thank you for your followup comments. I am in total agreement that it is a > shame the challenges we have faced and the progress we have made is not > better documented in the history of JBS tickets. I have been the worst > offender. I apologize. Please, no need to apologize. I understand that during early development one needs to move quickly. I just thought that your team's experience with tuning Shenandoah is valuable, and it is regrettable when it is lost. > You are correct that the change is to N, the number of times in a row that we > perform degenerated GC before we automatically upgrade to Full GC. It is > still possible that we will upgrade to Full GC before N is reached, because > there are other situations, such as lack of progress by degenerated GC, that > will cause us to upgrade to Full even before N is reached. > > The comment is still valid as written. During degenerated GC, the mutator > threads are all blocked, so the ONLY kind of allocation failure that can > occur during degenerated GC is a GC-worker-thread allocation for the purpose > of evacuating memory. If we experience an "evacuation failure" during > degenerated GC. we will upgrade to Full GC. Thank you for the thorough explanation. - PR Comment: https://git.openjdk.org/jdk/pull/14185#issuecomment-1581232734
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v17]
> 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 > command line that already specifies ` -XX:+UseShenandoahGC`. The > implementation automatically adjusts the sizes of old generation and young > generation to efficiently utilize the entire heap capacity. Generational > mode of Shenandoah resembles G1 in the following regards: > > 1. Old-generation marking runs concurrently during the time that multiple > young generation collections run to completion. > 2. After old-generation marking completes, we perform a sequence of mixed > collections. Each mixed collection combines collection of young generation > with evacuation of a portion of the old-generation regions identified for > collection based on old-generation marking information. > 3. Unlike G1, young-generation collections and evacuations are entirely > concurrent, as with single-generation Shenandoah. > 4. As with single-generation Shenandoah, there is no explicit notion of eden > and survivor space within the young generation. In practice, regions that > were most recently allocated tend to have large amounts of garbage and these > regions tend to be collected with very little effort. Young-generation > objects that survive garbage collection tend to accumulate in regions that > hold survivor objects. These regions tend to have smaller amounts of > garbage, and are less likely to be collected. If they survive a sufficient > number of young-generation collections, the “survivor” regions are promoted > into the old generation. > > We expect to refine heuristics as we gain experience with more production > workloads. In the future, we plan to remove the “experimental” qualifier > from generational mode, at which time we expect that generational mode will > become the default mode for Shenandoah. > > **Testing**: We continuously run jtreg tiers 1-4 + hotspot_gc_shenandoah, > gcstress, jck compiler, jck runtime, Dacapo, SpecJBB, SpecVM, Extremem, > HyperAlloc, and multiple AWS production workload simulators. We test on Linux > x64 and aarch64, Alpine x64 and aarch64, macOS x64 and aarch64, and Windows > x64. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Fix budgeting assertion to allow equal or greater than - Changes: - all: https://git.openjdk.org/jdk/pull/14185/files - new: https://git.openjdk.org/jdk/pull/14185/files/612072a4..19e62fe0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=14185=16 - incr: https://webrevs.openjdk.org/?repo=jdk=14185=15-16 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14185.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14185/head:pull/14185 PR: https://git.openjdk.org/jdk/pull/14185
Integrated: 8309420: com/sun/jdi/StepTest.java fails with virtual thread wrapper
On Mon, 5 Jun 2023 04:03:57 GMT, Chris Plummer wrote: > 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 virtual > threads, it is actually in TestScaffold.main() at this point, so the wrong > class name is gleaned from the frame. To fix this the test just saves away > the debuggee class name, which is passed to the test as the 4th argument. > > The other issue is that the test assumes once it gets to the debuggee go() > method, there are only two frames on the stack. It's more like 16 when using > virtual threads. The test needs to account for this by counting the number of > frames when go() is entered rather than assuming it will be 2. > > Tested locally with and without the wrapper and by running tier5 svc tests. This pull request has now been integrated. Changeset: e3f3ac08 Author:Chris Plummer URL: https://git.openjdk.org/jdk/commit/e3f3ac0825e63ef5cec8e5f7e53ee0dbee263ac4 Stats: 21 lines in 2 files changed: 10 ins; 4 del; 7 mod 8309420: com/sun/jdi/StepTest.java fails with virtual thread wrapper Reviewed-by: sspitsyn, amenkov - PR: https://git.openjdk.org/jdk/pull/14307
Re: RFR: 8309420: com/sun/jdi/StepTest.java fails with virtual thread wrapper
On Mon, 5 Jun 2023 04:03:57 GMT, Chris Plummer wrote: > 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 virtual > threads, it is actually in TestScaffold.main() at this point, so the wrong > class name is gleaned from the frame. To fix this the test just saves away > the debuggee class name, which is passed to the test as the 4th argument. > > The other issue is that the test assumes once it gets to the debuggee go() > method, there are only two frames on the stack. It's more like 16 when using > virtual threads. The test needs to account for this by counting the number of > frames when go() is entered rather than assuming it will be 2. > > Tested locally with and without the wrapper and by running tier5 svc tests. Thanks for the reviews Alex and Serguei! - PR Comment: https://git.openjdk.org/jdk/pull/14307#issuecomment-1581278317
Re: RFR: 8309510: com/sun/jdi/RedefineNestmateAttr/TestNestmateAttr.java no longer needs to override startUp() method
On Tue, 6 Jun 2023 00:36:12 GMT, Chris Plummer wrote:
> com/sun/jdi/RedefineNestmateAttr/TestNestmateAttr.java currently overrides
> the TestScaffold.startup() method:
>
> // override this to correct a bug so arguments can be passed to
> // the Target class
> protected void startUp(String targetName) {
> List argList = new ArrayList<>(Arrays.asList(args));
> argList.add(0, targetName); // pre-pend so it becomes the first "app"
> arg
> println("run args: " + argList);
> connect((String[]) argList.toArray(args));
> waitForVMStart();
> }
>
> This issue of passing app args was fixed recently by
> [JDK-8308481](https://bugs.openjdk.org/browse/JDK-8308481), so the override
> is no longer needed.
Thanks for the reviews Alex and Serguei!
-
PR Comment: https://git.openjdk.org/jdk/pull/14325#issuecomment-1581267545
Integrated: 8309510: com/sun/jdi/RedefineNestmateAttr/TestNestmateAttr.java no longer needs to override startUp() method
On Tue, 6 Jun 2023 00:36:12 GMT, Chris Plummer wrote:
> com/sun/jdi/RedefineNestmateAttr/TestNestmateAttr.java currently overrides
> the TestScaffold.startup() method:
>
> // override this to correct a bug so arguments can be passed to
> // the Target class
> protected void startUp(String targetName) {
> List argList = new ArrayList<>(Arrays.asList(args));
> argList.add(0, targetName); // pre-pend so it becomes the first "app"
> arg
> println("run args: " + argList);
> connect((String[]) argList.toArray(args));
> waitForVMStart();
> }
>
> This issue of passing app args was fixed recently by
> [JDK-8308481](https://bugs.openjdk.org/browse/JDK-8308481), so the override
> is no longer needed.
This pull request has now been integrated.
Changeset: c38abbfc
Author:Chris Plummer
URL:
https://git.openjdk.org/jdk/commit/c38abbfcaa80b3bb38bd6fc284e6bc3437199d77
Stats: 10 lines in 1 file changed: 0 ins; 10 del; 0 mod
8309510: com/sun/jdi/RedefineNestmateAttr/TestNestmateAttr.java no longer needs
to override startUp() method
Reviewed-by: sspitsyn, amenkov
-
PR: https://git.openjdk.org/jdk/pull/14325
Re: RFR: 8309509: com/sun/jdi/RedefineNestmateAttr/TestNestmateAttr.java fails with virtual test thread factory
On Tue, 6 Jun 2023 00:02:47 GMT, Chris Plummer wrote: > The test fails with the virtual test thread factory because it tries to find > the "main" thread in the list of threads returned by JDI, but "main" is a > virtual thread and will only be returned by JDI if the debug agent is > launched with includevirtualthreads=y. As a result the thread is not found > and the test asserts: > > java.lang.RuntimeException: assertTrue: expected true, was false > at jdk.test.lib.Asserts.fail(Asserts.java:594) > at jdk.test.lib.Asserts.assertTrue(Asserts.java:486) > at jdk.test.lib.Asserts.assertTrue(Asserts.java:472) > at TestNestmateAttr.checkGoodTransforms(TestNestmateAttr.java:511) > at TestNestmateAttr.methodEntered(TestNestmateAttr.java:320) > at TestScaffold$EventHandler.notifyEvent(TestScaffold.java:205) > at TestScaffold$EventHandler.run(TestScaffold.java:279) > at java.base/java.lang.Thread.run(Thread.java:1583) > > The fix is to always run the debug agent with includevirtualthreads=y. > > Tested by running all com/sun/jdi tests locally with and without the virtual > test thread factory. Also ran tier1 and tier5 svc test tasks. Thanks for the reviews Alex and Serguei! - PR Comment: https://git.openjdk.org/jdk/pull/14324#issuecomment-1581258561
Integrated: 8309509: com/sun/jdi/RedefineNestmateAttr/TestNestmateAttr.java fails with virtual test thread factory
On Tue, 6 Jun 2023 00:02:47 GMT, Chris Plummer wrote: > The test fails with the virtual test thread factory because it tries to find > the "main" thread in the list of threads returned by JDI, but "main" is a > virtual thread and will only be returned by JDI if the debug agent is > launched with includevirtualthreads=y. As a result the thread is not found > and the test asserts: > > java.lang.RuntimeException: assertTrue: expected true, was false > at jdk.test.lib.Asserts.fail(Asserts.java:594) > at jdk.test.lib.Asserts.assertTrue(Asserts.java:486) > at jdk.test.lib.Asserts.assertTrue(Asserts.java:472) > at TestNestmateAttr.checkGoodTransforms(TestNestmateAttr.java:511) > at TestNestmateAttr.methodEntered(TestNestmateAttr.java:320) > at TestScaffold$EventHandler.notifyEvent(TestScaffold.java:205) > at TestScaffold$EventHandler.run(TestScaffold.java:279) > at java.base/java.lang.Thread.run(Thread.java:1583) > > The fix is to always run the debug agent with includevirtualthreads=y. > > Tested by running all com/sun/jdi tests locally with and without the virtual > test thread factory. Also ran tier1 and tier5 svc test tasks. This pull request has now been integrated. Changeset: a54f4d4a Author:Chris Plummer URL: https://git.openjdk.org/jdk/commit/a54f4d4ab9537ac7e070dd82e26f73c90d82290a Stats: 7 lines in 2 files changed: 3 ins; 2 del; 2 mod 8309509: com/sun/jdi/RedefineNestmateAttr/TestNestmateAttr.java fails with virtual test thread factory Reviewed-by: sspitsyn, amenkov - PR: https://git.openjdk.org/jdk/pull/14324
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v16]
> 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 > command line that already specifies ` -XX:+UseShenandoahGC`. The > implementation automatically adjusts the sizes of old generation and young > generation to efficiently utilize the entire heap capacity. Generational > mode of Shenandoah resembles G1 in the following regards: > > 1. Old-generation marking runs concurrently during the time that multiple > young generation collections run to completion. > 2. After old-generation marking completes, we perform a sequence of mixed > collections. Each mixed collection combines collection of young generation > with evacuation of a portion of the old-generation regions identified for > collection based on old-generation marking information. > 3. Unlike G1, young-generation collections and evacuations are entirely > concurrent, as with single-generation Shenandoah. > 4. As with single-generation Shenandoah, there is no explicit notion of eden > and survivor space within the young generation. In practice, regions that > were most recently allocated tend to have large amounts of garbage and these > regions tend to be collected with very little effort. Young-generation > objects that survive garbage collection tend to accumulate in regions that > hold survivor objects. These regions tend to have smaller amounts of > garbage, and are less likely to be collected. If they survive a sufficient > number of young-generation collections, the “survivor” regions are promoted > into the old generation. > > We expect to refine heuristics as we gain experience with more production > workloads. In the future, we plan to remove the “experimental” qualifier > from generational mode, at which time we expect that generational mode will > become the default mode for Shenandoah. > > **Testing**: We continuously run jtreg tiers 1-4 + hotspot_gc_shenandoah, > gcstress, jck compiler, jck runtime, Dacapo, SpecJBB, SpecVM, Extremem, > HyperAlloc, and multiple AWS production workload simulators. We test on Linux > x64 and aarch64, Alpine x64 and aarch64, macOS x64 and aarch64, and Windows > x64. Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 305 commits: - Merge branch 'master' of https://git.openjdk.org/jdk into merge-generational-shenandoah - Simplify test logic, fail if name of Shenandoah young gen pool changes (#3) - Remove a few more unneeded copyright notices - Remove more extraneous copyright notices - JDK-8309322: [GenShen] TestAllocOutOfMemory#large failed When generational Shenandoah is used, there may be an additional alignment related heap size adjustment that the test should be cognizant of. Such alignment might also happen in the non-generational case, but in this case the specific size used in the test was affected on machines with larger than usual os page size settings. The alignment related adjustment would have affected all generational collectors (except perhaps Gen Z). In the future, we might try and relax this alignment constraint.alignment. - Remove one more extraneous Amazon copyright - Update copyright notices - Improve efficiency of card-size alignment calculations - Exit during initialization on unsupported platforms - Remove an inappropriate copyright notice - ... and 295 more: https://git.openjdk.org/jdk/compare/33bb64f2...612072a4 - Changes: https://git.openjdk.org/jdk/pull/14185/files Webrev: https://webrevs.openjdk.org/?repo=jdk=14185=15 Stats: 20143 lines in 202 files changed: 18218 ins; 916 del; 1009 mod Patch: https://git.openjdk.org/jdk/pull/14185.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14185/head:pull/14185 PR: https://git.openjdk.org/jdk/pull/14185
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v15]
> 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 > command line that already specifies ` -XX:+UseShenandoahGC`. The > implementation automatically adjusts the sizes of old generation and young > generation to efficiently utilize the entire heap capacity. Generational > mode of Shenandoah resembles G1 in the following regards: > > 1. Old-generation marking runs concurrently during the time that multiple > young generation collections run to completion. > 2. After old-generation marking completes, we perform a sequence of mixed > collections. Each mixed collection combines collection of young generation > with evacuation of a portion of the old-generation regions identified for > collection based on old-generation marking information. > 3. Unlike G1, young-generation collections and evacuations are entirely > concurrent, as with single-generation Shenandoah. > 4. As with single-generation Shenandoah, there is no explicit notion of eden > and survivor space within the young generation. In practice, regions that > were most recently allocated tend to have large amounts of garbage and these > regions tend to be collected with very little effort. Young-generation > objects that survive garbage collection tend to accumulate in regions that > hold survivor objects. These regions tend to have smaller amounts of > garbage, and are less likely to be collected. If they survive a sufficient > number of young-generation collections, the “survivor” regions are promoted > into the old generation. > > We expect to refine heuristics as we gain experience with more production > workloads. In the future, we plan to remove the “experimental” qualifier > from generational mode, at which time we expect that generational mode will > become the default mode for Shenandoah. > > **Testing**: We continuously run jtreg tiers 1-4 + hotspot_gc_shenandoah, > gcstress, jck compiler, jck runtime, Dacapo, SpecJBB, SpecVM, Extremem, > HyperAlloc, and multiple AWS production workload simulators. We test on Linux > x64 and aarch64, Alpine x64 and aarch64, macOS x64 and aarch64, and Windows > x64. Kelvin Nilsen has updated the pull request incrementally with 174 additional commits since the last revision: - 8309614: [BACKOUT] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING Reviewed-by: azvegint - 8308288: Fix xlc17 clang warnings and build errors in hotspot Reviewed-by: goetz, mbaesken - 8309225: Fix xlc17 clang 15 warnings in security and servicability Reviewed-by: goetz, mdoerr, clanger - 8309219: Fix xlc17 clang 15 warnings in java.base Reviewed-by: goetz, mdoerr - 8307153: JVMTI GetThreadState on carrier should return STATE_WAITING Reviewed-by: amenkov, cjplummer - 8309543: Micro-optimize x86 assembler UseCondCardMark Reviewed-by: kvn, mdoerr - 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots Reviewed-by: prr, kizune, psadhukhan - 8309550: jdk.jfr.internal.Utils::formatDataAmount method should gracefully handle amounts equal to Long.MIN_VALUE Reviewed-by: stuefe, mgronlun - 8308445: Linker should check that capture state segment is big enough Reviewed-by: mcimadamore - 8308031: Linkers should reject unpromoted variadic parameters Reviewed-by: mcimadamore - ... and 164 more: https://git.openjdk.org/jdk/compare/240d413d...8b2edd9c - Changes: - all: https://git.openjdk.org/jdk/pull/14185/files - new: https://git.openjdk.org/jdk/pull/14185/files/240d413d..8b2edd9c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=14185=14 - incr: https://webrevs.openjdk.org/?repo=jdk=14185=13-14 Stats: 55913 lines in 825 files changed: 45254 ins; 7582 del; 3077 mod Patch: https://git.openjdk.org/jdk/pull/14185.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14185/head:pull/14185 PR: https://git.openjdk.org/jdk/pull/14185
Re: RFR: 8309602: update JVMTI history table for jdk 21 [v3]
On Wed, 7 Jun 2023 13:08:00 GMT, Serguei Spitsyn wrote: >> This is a minor update of the `jvmti.xml` file. >> The JVM TI history table needs to be updated to list: >> - Virtual threads finalized to be a permanent feature. >> - Agent start-up in the live phase now specified to print a warning. >> >> The JVM TI history table has no normative changes. This update does not need >> a CSR. > > Serguei Spitsyn has updated the pull request incrementally with one > additional commit since the last revision: > > review: minor history table tweak Thanks! - Marked as reviewed by iris (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14352#pullrequestreview-1468021106
Re: RFR: 8309614: [BACKOUT] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING
On Wed, 7 Jun 2023 14:33:51 GMT, Daniel D. Daugherty wrote: > This reverts commit 177e8327d685444d63235567f2a9bde0ec3d51cf. macosx-aarch64-debug has now passed with the [BACKOUT]. That config failed in 2 of the 3 Tier1 job sets that had sightings of this failure mode. - PR Comment: https://git.openjdk.org/jdk/pull/14359#issuecomment-1581049185
Integrated: 8309614: [BACKOUT] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING
On Wed, 7 Jun 2023 14:33:51 GMT, Daniel D. Daugherty wrote: > This reverts commit 177e8327d685444d63235567f2a9bde0ec3d51cf. This pull request has now been integrated. Changeset: 33bb64f2 Author:Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/33bb64f24fdffdb2b1a5f21ff432b1cee9ead498 Stats: 82 lines in 4 files changed: 0 ins; 65 del; 17 mod 8309614: [BACKOUT] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING Reviewed-by: azvegint - PR: https://git.openjdk.org/jdk/pull/14359
Re: RFR: 8309614: [BACKOUT] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING
On Wed, 7 Jun 2023 14:33:51 GMT, Daniel D. Daugherty wrote: > This reverts commit 177e8327d685444d63235567f2a9bde0ec3d51cf. linux-aarch64-debug has now passed with the [BACKOUT]. That config failed in 2 of the 3 Tier1 job sets that had sightings of this failure mode. windows-x64-debug has now passed with the [BACKOUT]. That config failed in 1 of the 3 Tier1 job sets that had sightings of this failure mode. macosx-x64-debug has now passed with the [BACKOUT]. That config failed in 2 of the 3 Tier1 job sets that had sightings of this failure mode. - PR Comment: https://git.openjdk.org/jdk/pull/14359#issuecomment-1581027842 PR Comment: https://git.openjdk.org/jdk/pull/14359#issuecomment-1581030425 PR Comment: https://git.openjdk.org/jdk/pull/14359#issuecomment-1581033097
Re: RFR: 8309614: [BACKOUT] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING
On Wed, 7 Jun 2023 14:33:51 GMT, Daniel D. Daugherty wrote: > This reverts commit 177e8327d685444d63235567f2a9bde0ec3d51cf. The linux-x64-debug config has passed with the [BACKOUT]. That config failed in each of the three Tier1 job sets that had sightings of this failure mode. - PR Comment: https://git.openjdk.org/jdk/pull/14359#issuecomment-1581015467
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v14]
> 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 > command line that already specifies ` -XX:+UseShenandoahGC`. The > implementation automatically adjusts the sizes of old generation and young > generation to efficiently utilize the entire heap capacity. Generational > mode of Shenandoah resembles G1 in the following regards: > > 1. Old-generation marking runs concurrently during the time that multiple > young generation collections run to completion. > 2. After old-generation marking completes, we perform a sequence of mixed > collections. Each mixed collection combines collection of young generation > with evacuation of a portion of the old-generation regions identified for > collection based on old-generation marking information. > 3. Unlike G1, young-generation collections and evacuations are entirely > concurrent, as with single-generation Shenandoah. > 4. As with single-generation Shenandoah, there is no explicit notion of eden > and survivor space within the young generation. In practice, regions that > were most recently allocated tend to have large amounts of garbage and these > regions tend to be collected with very little effort. Young-generation > objects that survive garbage collection tend to accumulate in regions that > hold survivor objects. These regions tend to have smaller amounts of > garbage, and are less likely to be collected. If they survive a sufficient > number of young-generation collections, the “survivor” regions are promoted > into the old generation. > > We expect to refine heuristics as we gain experience with more production > workloads. In the future, we plan to remove the “experimental” qualifier > from generational mode, at which time we expect that generational mode will > become the default mode for Shenandoah. > > **Testing**: We continuously run jtreg tiers 1-4 + hotspot_gc_shenandoah, > gcstress, jck compiler, jck runtime, Dacapo, SpecJBB, SpecVM, Extremem, > HyperAlloc, and multiple AWS production workload simulators. We test on Linux > x64 and aarch64, Alpine x64 and aarch64, macOS x64 and aarch64, and Windows > x64. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Simplify test logic, fail if name of Shenandoah young gen pool changes (#3) - Changes: - all: https://git.openjdk.org/jdk/pull/14185/files - new: https://git.openjdk.org/jdk/pull/14185/files/01c62516..240d413d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=14185=13 - incr: https://webrevs.openjdk.org/?repo=jdk=14185=12-13 Stats: 13 lines in 1 file changed: 0 ins; 9 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/14185.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14185/head:pull/14185 PR: https://git.openjdk.org/jdk/pull/14185
Re: RFR: JDK-8309462: vmTestbase/nsk/jvmti/RunAgentThread/agentthr001/TestDescription.java crashing due to empty while loop [v3]
On Wed, 7 Jun 2023 14:04:14 GMT, JoKern65 wrote:
>> The sys_thread_3() function contains an empty while loop, which by the
>> standard can be optimized away. Please refer to discussion in
>> https://github.com/llvm/llvm-project/issues/60622
>> The xlc17 compiler is doing so, and IBM claims that they are following the
>> standard and will not fix this on compiler side.
>> So we have (at least) 3 ways to circumvent this behavior.
>>
>> 1. we can introduce the call of a nop library function, which will hinder
>> the optimizer to throw away the loop (This is our proposed solution, but
>> instead of a heavy looping thread, the result is a more or less idle thread):
>> `#include `
>> `static void`
>> `sys_thread_3(jvmtiEnv* jvmti, JNIEnv* jni, void *p)`
>> `{`
>> `while (1) {`
>> ` sleep(1);`
>> `}`
>> `}`
>>
>> 2. We can make use of a volatile variable in the loop body which also
>> hinders the optimizer to throw away the loop:
>> `static void`
>> `sys_thread_3(jvmtiEnv* jvmti, JNIEnv* jni, void *p)`
>> `{`
>> `volatile int i = 1;`
>> `while (i) {`
>> ` i += 2;`
>> `}`
>> `}`
>>
>> 3. we can use the __attribute__ ((optnone)) modifier in the function
>> declaration to suppress the optimization at all:
>> `static void`
>> `sys_thread_3(jvmtiEnv* jvmti, JNIEnv* jni, void *p) __attribute__
>> ((optnone))`
>> `{`
>> `while (1) {`
>> `}`
>> `}`
>>
>> To make the third approach platform independent, we can implement it in the
>> following way:
>> In globalDefinitions.hpp
>> `#ifndef OPTNONE`
>> `#define OPTNONE`
>> `#endif`
>>
>> In globalDefinitions_xlc.hpp
>> `// optnone support`
>> `//`
>> `// To use if a function should not be optimized`
>> `// Usage:`
>> `// void* func(size_t size) OPTNONE {...}`
>> `#define OPTNONE __attribute__(( optnone))`
>>
>> With this we can change libagentthr001.cpp in a platform independent way to
>> `static void`
>> `sys_thread_3(jvmtiEnv* jvmti, JNIEnv* jni, void *p) OPTNONE`
>> `{`
>> ` while (1) {`
>> ` }`
>> `}`
>
> JoKern65 has updated the pull request incrementally with one additional
> commit since the last revision:
>
> remove d042520_libagentthr.diff
Marked as reviewed by clanger (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/14330#pullrequestreview-1467898282
Re: RFR: 8309614: [BACKOUT] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING
On Wed, 7 Jun 2023 14:43:45 GMT, Alexander Zvegintsev wrote: >> This reverts commit 177e8327d685444d63235567f2a9bde0ec3d51cf. > > Marked as reviewed by azvegint (Reviewer). @azvegint - Thanks for the fast review! I'm still waiting for my urgent Tier1 test results... - PR Comment: https://git.openjdk.org/jdk/pull/14359#issuecomment-1580982837
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v13]
> 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 > command line that already specifies ` -XX:+UseShenandoahGC`. The > implementation automatically adjusts the sizes of old generation and young > generation to efficiently utilize the entire heap capacity. Generational > mode of Shenandoah resembles G1 in the following regards: > > 1. Old-generation marking runs concurrently during the time that multiple > young generation collections run to completion. > 2. After old-generation marking completes, we perform a sequence of mixed > collections. Each mixed collection combines collection of young generation > with evacuation of a portion of the old-generation regions identified for > collection based on old-generation marking information. > 3. Unlike G1, young-generation collections and evacuations are entirely > concurrent, as with single-generation Shenandoah. > 4. As with single-generation Shenandoah, there is no explicit notion of eden > and survivor space within the young generation. In practice, regions that > were most recently allocated tend to have large amounts of garbage and these > regions tend to be collected with very little effort. Young-generation > objects that survive garbage collection tend to accumulate in regions that > hold survivor objects. These regions tend to have smaller amounts of > garbage, and are less likely to be collected. If they survive a sufficient > number of young-generation collections, the “survivor” regions are promoted > into the old generation. > > We expect to refine heuristics as we gain experience with more production > workloads. In the future, we plan to remove the “experimental” qualifier > from generational mode, at which time we expect that generational mode will > become the default mode for Shenandoah. > > **Testing**: We continuously run jtreg tiers 1-4 + hotspot_gc_shenandoah, > gcstress, jck compiler, jck runtime, Dacapo, SpecJBB, SpecVM, Extremem, > HyperAlloc, and multiple AWS production workload simulators. We test on Linux > x64 and aarch64, Alpine x64 and aarch64, macOS x64 and aarch64, and Windows > x64. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Remove a few more unneeded copyright notices - Changes: - all: https://git.openjdk.org/jdk/pull/14185/files - new: https://git.openjdk.org/jdk/pull/14185/files/8e5c3b73..01c62516 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=14185=12 - incr: https://webrevs.openjdk.org/?repo=jdk=14185=11-12 Stats: 9 lines in 9 files changed: 0 ins; 9 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14185.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14185/head:pull/14185 PR: https://git.openjdk.org/jdk/pull/14185
Re: RFR: 8309614: [BACKOUT] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING
On Wed, 7 Jun 2023 14:33:51 GMT, Daniel D. Daugherty wrote: > This reverts commit 177e8327d685444d63235567f2a9bde0ec3d51cf. Marked as reviewed by azvegint (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/14359#pullrequestreview-1467877421
Re: RFR: 8307153: JVMTI GetThreadState on carrier should return STATE_WAITING [v6]
On Wed, 7 Jun 2023 11:48:19 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_WAITING | JVMTI_THREAD_STATE_WAITING_INDEFINITELY. >> The fix adds: >> - a special case for passive carrier threads >> - necessary test coverage to the existing JVMTI test: >> `serviceability/jvmti/vthread/ThreadStateTest`. >> >> Testing: >>- tested with the updated test: >> `serviceability/jvmti/vthread/ThreadStateTest` >>- submitted mach5 tiers 1-5 >>- TBD: to submit mach5 tier 6 > > Serguei Spitsyn has updated the pull request incrementally with one > additional commit since the last revision: > > review: one function renaming Looks like this PR has caused regression failures in Tier1. We have between 2 and 5 failures per Tier1. See: [JDK-8309612](https://bugs.openjdk.org/browse/JDK-8309612) serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java#default fails after JDK-8307153 Because this failure is happening in Tier1, combined with the fact that we get much more JVM/TI testing in the upper Tiers, and tomorrow is the code-fork I'm proceeding with a [BACKOUT] and am testing that [BACKOUT] with an urgent Tier1 right now. See: [JDK-8309614](https://bugs.openjdk.org/browse/JDK-8309614) [BACKOUT] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING - PR Comment: https://git.openjdk.org/jdk/pull/14298#issuecomment-1580968712
RFR: 8309614: [BACKOUT] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING
This reverts commit 177e8327d685444d63235567f2a9bde0ec3d51cf. - Commit messages: - Revert "8307153: JVMTI GetThreadState on carrier should return STATE_WAITING" Changes: https://git.openjdk.org/jdk/pull/14359/files Webrev: https://webrevs.openjdk.org/?repo=jdk=14359=00 Issue: https://bugs.openjdk.org/browse/JDK-8309614 Stats: 82 lines in 4 files changed: 0 ins; 65 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/14359.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14359/head:pull/14359 PR: https://git.openjdk.org/jdk/pull/14359
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v9]
On Wed, 7 Jun 2023 07:34:44 GMT, Y. Srinivas Ramakrishna wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update copyright notices > > src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.hpp line 3: > >> 1: /* >> 2: * Copyright (c) 2018, 2021, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > Should probably be removed. removed. > src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.hpp line 3: > >> 1: /* >> 2: * Copyright (c) 2018, 2021, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > Check if this is necessary. ok. i'll remove. > src/hotspot/share/gc/shenandoah/heuristics/shenandoahCompactHeuristics.hpp > line 3: > >> 1: /* >> 2: * Copyright (c) 2018, 2019, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > Can be removed? removed. > src/hotspot/share/gc/shenandoah/heuristics/shenandoahPassiveHeuristics.hpp > line 3: > >> 1: /* >> 2: * Copyright (c) 2018, 2019, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > Should be removed? removed. > src/hotspot/share/gc/shenandoah/heuristics/shenandoahStaticHeuristics.hpp > line 3: > >> 1: /* >> 2: * Copyright (c) 2018, 2019, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > Should be removed? removed. > src/hotspot/share/gc/shenandoah/mode/shenandoahPassiveMode.hpp line 3: > >> 1: /* >> 2: * Copyright (c) 2019, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > Should be removed? removed. > src/hotspot/share/gc/shenandoah/mode/shenandoahSATBMode.cpp line 3: > >> 1: /* >> 2: * Copyright (c) 2019, 2021, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > Can be removed. removed. > src/hotspot/share/gc/shenandoah/shenandoahBarrierSetClone.inline.hpp line 3: > >> 1: /* >> 2: * Copyright (c) 2013, 2021, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > Unnecessary. Delete. removed. > src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.hpp line 3: > >> 1: /* >> 2: * Copyright (c) 2013, 2021, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > Probably unnecessary. removed. - PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221700458 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221704676 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221706236 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221707142 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221709229 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221710192 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221711143 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221712173 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221713033
Re: RFR: JDK-8309462: vmTestbase/nsk/jvmti/RunAgentThread/agentthr001/TestDescription.java crashing due to empty while loop [v3]
On Wed, 7 Jun 2023 14:04:14 GMT, JoKern65 wrote:
>> The sys_thread_3() function contains an empty while loop, which by the
>> standard can be optimized away. Please refer to discussion in
>> https://github.com/llvm/llvm-project/issues/60622
>> The xlc17 compiler is doing so, and IBM claims that they are following the
>> standard and will not fix this on compiler side.
>> So we have (at least) 3 ways to circumvent this behavior.
>>
>> 1. we can introduce the call of a nop library function, which will hinder
>> the optimizer to throw away the loop (This is our proposed solution, but
>> instead of a heavy looping thread, the result is a more or less idle thread):
>> `#include `
>> `static void`
>> `sys_thread_3(jvmtiEnv* jvmti, JNIEnv* jni, void *p)`
>> `{`
>> `while (1) {`
>> ` sleep(1);`
>> `}`
>> `}`
>>
>> 2. We can make use of a volatile variable in the loop body which also
>> hinders the optimizer to throw away the loop:
>> `static void`
>> `sys_thread_3(jvmtiEnv* jvmti, JNIEnv* jni, void *p)`
>> `{`
>> `volatile int i = 1;`
>> `while (i) {`
>> ` i += 2;`
>> `}`
>> `}`
>>
>> 3. we can use the __attribute__ ((optnone)) modifier in the function
>> declaration to suppress the optimization at all:
>> `static void`
>> `sys_thread_3(jvmtiEnv* jvmti, JNIEnv* jni, void *p) __attribute__
>> ((optnone))`
>> `{`
>> `while (1) {`
>> `}`
>> `}`
>>
>> To make the third approach platform independent, we can implement it in the
>> following way:
>> In globalDefinitions.hpp
>> `#ifndef OPTNONE`
>> `#define OPTNONE`
>> `#endif`
>>
>> In globalDefinitions_xlc.hpp
>> `// optnone support`
>> `//`
>> `// To use if a function should not be optimized`
>> `// Usage:`
>> `// void* func(size_t size) OPTNONE {...}`
>> `#define OPTNONE __attribute__(( optnone))`
>>
>> With this we can change libagentthr001.cpp in a platform independent way to
>> `static void`
>> `sys_thread_3(jvmtiEnv* jvmti, JNIEnv* jni, void *p) OPTNONE`
>> `{`
>> ` while (1) {`
>> ` }`
>> `}`
>
> JoKern65 has updated the pull request incrementally with one additional
> commit since the last revision:
>
> remove d042520_libagentthr.diff
I don't like empty endless loops in general, but I think your solution is ok
for a test.
-
Marked as reviewed by mdoerr (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/14330#pullrequestreview-1467779695
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v9]
On Wed, 7 Jun 2023 07:52:35 GMT, Y. Srinivas Ramakrishna wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update copyright notices > > src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.hpp line 3: > >> 1: /* >> 2: * Copyright (c) 2021, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > Unnecessary. Thanks Ramki for sifting through these again. Sorry I missed so many. I'm making your suggested fixes. - PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221612109
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v12]
On Wed, 7 Jun 2023 13:37:44 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:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational` to a >> command line that already specifies ` -XX:+UseShenandoahGC`. The >> implementation automatically adjusts the sizes of old generation and young >> generation to efficiently utilize the entire heap capacity. Generational >> mode of Shenandoah resembles G1 in the following regards: >> >> 1. Old-generation marking runs concurrently during the time that multiple >> young generation collections run to completion. >> 2. After old-generation marking completes, we perform a sequence of mixed >> collections. Each mixed collection combines collection of young generation >> with evacuation of a portion of the old-generation regions identified for >> collection based on old-generation marking information. >> 3. Unlike G1, young-generation collections and evacuations are entirely >> concurrent, as with single-generation Shenandoah. >> 4. As with single-generation Shenandoah, there is no explicit notion of eden >> and survivor space within the young generation. In practice, regions that >> were most recently allocated tend to have large amounts of garbage and these >> regions tend to be collected with very little effort. Young-generation >> objects that survive garbage collection tend to accumulate in regions that >> hold survivor objects. These regions tend to have smaller amounts of >> garbage, and are less likely to be collected. If they survive a sufficient >> number of young-generation collections, the “survivor” regions are promoted >> into the old generation. >> >> We expect to refine heuristics as we gain experience with more production >> workloads. In the future, we plan to remove the “experimental” qualifier >> from generational mode, at which time we expect that generational mode will >> become the default mode for Shenandoah. >> >> **Testing**: We continuously run jtreg tiers 1-4 + hotspot_gc_shenandoah, >> gcstress, jck compiler, jck runtime, Dacapo, SpecJBB, SpecVM, Extremem, >> HyperAlloc, and multiple AWS production workload simulators. We test on >> Linux x64 and aarch64, Alpine x64 and aarch64, macOS x64 and aarch64, and >> Windows x64. > > Kelvin Nilsen has updated the pull request incrementally with one additional > commit since the last revision: > > Remove more extraneous copyright notices Hi Thomas, Thank you for your followup comments. I am in total agreement that it is a shame the challenges we have faced and the progress we have made is not better documented in the history of JBS tickets. I have been the worst offender. I apologize. One aspect of this problem is that our work has included a large degree of uncertainty and "research", and it is not always clear to us what needs to be addressed until after we finish and test certain fixes as integrated with a variety of other fixes. We will commit to being more engaged with JBS from this point forward, both for any further work done on the Shenandoah branch, and definitely for work done on tip. You are correct that the change is to N, the number of times in a row that we perform degenerated GC before we automatically upgrade to Full GC. It is still possible that we will upgrade to Full GC before N is reached, because there are other situations, such as lack of progress by degenerated GC, that will cause us to upgrade to Full even before N is reached. The comment is still valid as written. During degenerated GC, the mutator threads are all blocked, so the ONLY kind of allocation failure that can occur during degenerated GC is a GC-worker-thread allocation for the purpose of evacuating memory. If we experience an "evacuation failure" during degenerated GC. we will upgrade to Full GC. - PR Comment: https://git.openjdk.org/jdk/pull/14185#issuecomment-1580896496
Re: RFR: JDK-8309462: vmTestbase/nsk/jvmti/RunAgentThread/agentthr001/TestDescription.java crashing due to empty while loop [v3]
> The sys_thread_3() function contains an empty while loop, which by the
> standard can be optimized away. Please refer to discussion in
> https://github.com/llvm/llvm-project/issues/60622
> The xlc17 compiler is doing so, and IBM claims that they are following the
> standard and will not fix this on compiler side.
> So we have (at least) 3 ways to circumvent this behavior.
>
> 1. we can introduce the call of a nop library function, which will hinder the
> optimizer to throw away the loop (This is our proposed solution, but instead
> of a heavy looping thread, the result is a more or less idle thread):
> `#include `
> `static void`
> `sys_thread_3(jvmtiEnv* jvmti, JNIEnv* jni, void *p)`
> `{`
> `while (1) {`
> ` sleep(1);`
> `}`
> `}`
>
> 2. We can make use of a volatile variable in the loop body which also hinders
> the optimizer to throw away the loop:
> `static void`
> `sys_thread_3(jvmtiEnv* jvmti, JNIEnv* jni, void *p)`
> `{`
> `volatile int i = 1;`
> `while (i) {`
> ` i += 2;`
> `}`
> `}`
>
> 3. we can use the __attribute__ ((optnone)) modifier in the function
> declaration to suppress the optimization at all:
> `static void`
> `sys_thread_3(jvmtiEnv* jvmti, JNIEnv* jni, void *p) __attribute__
> ((optnone))`
> `{`
> `while (1) {`
> `}`
> `}`
>
> To make the third approach platform independent, we can implement it in the
> following way:
> In globalDefinitions.hpp
> `#ifndef OPTNONE`
> `#define OPTNONE`
> `#endif`
>
> In globalDefinitions_xlc.hpp
> `// optnone support`
> `//`
> `// To use if a function should not be optimized`
> `// Usage:`
> `// void* func(size_t size) OPTNONE {...}`
> `#define OPTNONE __attribute__(( optnone))`
>
> With this we can change libagentthr001.cpp in a platform independent way to
> `static void`
> `sys_thread_3(jvmtiEnv* jvmti, JNIEnv* jni, void *p) OPTNONE`
> `{`
> ` while (1) {`
> ` }`
> `}`
JoKern65 has updated the pull request incrementally with one additional commit
since the last revision:
remove d042520_libagentthr.diff
-
Changes:
- all: https://git.openjdk.org/jdk/pull/14330/files
- new: https://git.openjdk.org/jdk/pull/14330/files/e44edba6..e49f2759
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk=14330=02
- incr: https://webrevs.openjdk.org/?repo=jdk=14330=01-02
Stats: 26 lines in 1 file changed: 0 ins; 26 del; 0 mod
Patch: https://git.openjdk.org/jdk/pull/14330.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/14330/head:pull/14330
PR: https://git.openjdk.org/jdk/pull/14330
Re: RFR: JDK-8309462: vmTestbase/nsk/jvmti/RunAgentThread/agentthr001/TestDescription.java crashing due to empty while loop [v2]
> The sys_thread_3() function contains an empty while loop, which by the
> standard can be optimized away. Please refer to discussion in
> https://github.com/llvm/llvm-project/issues/60622
> The xlc17 compiler is doing so, and IBM claims that they are following the
> standard and will not fix this on compiler side.
> So we have (at least) 3 ways to circumvent this behavior.
>
> 1. we can introduce the call of a nop library function, which will hinder the
> optimizer to throw away the loop (This is our proposed solution, but instead
> of a heavy looping thread, the result is a more or less idle thread):
> `#include `
> `static void`
> `sys_thread_3(jvmtiEnv* jvmti, JNIEnv* jni, void *p)`
> `{`
> `while (1) {`
> ` sleep(1);`
> `}`
> `}`
>
> 2. We can make use of a volatile variable in the loop body which also hinders
> the optimizer to throw away the loop:
> `static void`
> `sys_thread_3(jvmtiEnv* jvmti, JNIEnv* jni, void *p)`
> `{`
> `volatile int i = 1;`
> `while (i) {`
> ` i += 2;`
> `}`
> `}`
>
> 3. we can use the __attribute__ ((optnone)) modifier in the function
> declaration to suppress the optimization at all:
> `static void`
> `sys_thread_3(jvmtiEnv* jvmti, JNIEnv* jni, void *p) __attribute__
> ((optnone))`
> `{`
> `while (1) {`
> `}`
> `}`
>
> To make the third approach platform independent, we can implement it in the
> following way:
> In globalDefinitions.hpp
> `#ifndef OPTNONE`
> `#define OPTNONE`
> `#endif`
>
> In globalDefinitions_xlc.hpp
> `// optnone support`
> `//`
> `// To use if a function should not be optimized`
> `// Usage:`
> `// void* func(size_t size) OPTNONE {...}`
> `#define OPTNONE __attribute__(( optnone))`
>
> With this we can change libagentthr001.cpp in a platform independent way to
> `static void`
> `sys_thread_3(jvmtiEnv* jvmti, JNIEnv* jni, void *p) OPTNONE`
> `{`
> ` while (1) {`
> ` }`
> `}`
JoKern65 has updated the pull request incrementally with one additional commit
since the last revision:
switched to solution two
-
Changes:
- all: https://git.openjdk.org/jdk/pull/14330/files
- new: https://git.openjdk.org/jdk/pull/14330/files/ae0d67ae..e44edba6
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk=14330=01
- incr: https://webrevs.openjdk.org/?repo=jdk=14330=00-01
Stats: 32 lines in 2 files changed: 29 ins; 1 del; 2 mod
Patch: https://git.openjdk.org/jdk/pull/14330.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/14330/head:pull/14330
PR: https://git.openjdk.org/jdk/pull/14330
Re: RFR: JDK-8309462: vmTestbase/nsk/jvmti/RunAgentThread/agentthr001/TestDescription.java crashing due to empty while loop
On Tue, 6 Jun 2023 09:51:09 GMT, JoKern65 wrote:
> The sys_thread_3() function contains an empty while loop, which by the
> standard can be optimized away. Please refer to discussion in
> https://github.com/llvm/llvm-project/issues/60622
> The xlc17 compiler is doing so, and IBM claims that they are following the
> standard and will not fix this on compiler side.
> So we have (at least) 3 ways to circumvent this behavior.
>
> 1. we can introduce the call of a nop library function, which will hinder the
> optimizer to throw away the loop (This is our proposed solution, but instead
> of a heavy looping thread, the result is a more or less idle thread):
> `#include `
> `static void`
> `sys_thread_3(jvmtiEnv* jvmti, JNIEnv* jni, void *p)`
> `{`
> `while (1) {`
> ` sleep(1);`
> `}`
> `}`
>
> 2. We can make use of a volatile variable in the loop body which also hinders
> the optimizer to throw away the loop:
> `static void`
> `sys_thread_3(jvmtiEnv* jvmti, JNIEnv* jni, void *p)`
> `{`
> `volatile int i = 1;`
> `while (i) {`
> ` i += 2;`
> `}`
> `}`
>
> 3. we can use the __attribute__ ((optnone)) modifier in the function
> declaration to suppress the optimization at all:
> `static void`
> `sys_thread_3(jvmtiEnv* jvmti, JNIEnv* jni, void *p) __attribute__
> ((optnone))`
> `{`
> `while (1) {`
> `}`
> `}`
>
> To make the third approach platform independent, we can implement it in the
> following way:
> In globalDefinitions.hpp
> `#ifndef OPTNONE`
> `#define OPTNONE`
> `#endif`
>
> In globalDefinitions_xlc.hpp
> `// optnone support`
> `//`
> `// To use if a function should not be optimized`
> `// Usage:`
> `// void* func(size_t size) OPTNONE {...}`
> `#define OPTNONE __attribute__(( optnone))`
>
> With this we can change libagentthr001.cpp in a platform independent way to
> `static void`
> `sys_thread_3(jvmtiEnv* jvmti, JNIEnv* jni, void *p) OPTNONE`
> `{`
> ` while (1) {`
> ` }`
> `}`
Pre-submit failures:
C:/hostedtoolcache/windows/Java_Temurin-Hotspot_jdk/11.0.19-7/x64/bin/javac:
Bad address
on both windows, unrelated to this change. This was seen lately repeatedly.
-
PR Comment: https://git.openjdk.org/jdk/pull/14330#issuecomment-1580865446
Integrated: JDK-8309225: Fix xlc17 clang 15 warnings in security and servicability
On Fri, 2 Jun 2023 10:19:53 GMT, JoKern65 wrote:
> This pr is a split off from JDK-8308288: Fix xlc17 clang warnings in shared
> code https://github.com/openjdk/jdk/pull/14146
> It handles the part in security and servicability.
>
> Compiling on AIX with xlc17 which contains the new clang 15 frontend shows
> the following warnings:
>
> src/java.security.jgss/share/native/libj2gss/NativeUtil.h:30:
> src/java.security.jgss/share/native/libj2gss/gssapi.h:48:5: error:
> 'TARGET_OS_MAC' is not defined, evaluates to 0 [-Werror,-Wundef]
> #if TARGET_OS_MAC && (defined(ppc) || defined(ppc64) || defined(i386) ||
> defined(x86_64))
> ^
> TARGET_OS_MAC is not defined. Instead of disabling the warning, I could
> ` #ifndef TARGET_OS_MAC`
> `#define TARGET_OS_MAC=0`
> `#endif`
> But this is already handled by disabling the warning for gcc.
>
> src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c:718:33: error:
> suggest braces around initialization of subobject [-Werror,-Wmissing-braces]
> struct in6_addr mappedAny = IN6ADDR_ANY_INIT;
> ^~~~
> /usr/include/netinet/in.h:454:32: note: expanded from macro 'IN6ADDR_ANY_INIT'
> #define IN6ADDR_ANY_INIT {0, 0, 0, 0}
This pull request has now been integrated.
Changeset: 89f5baca
Author:JoKern65
Committer: Martin Doerr
URL:
https://git.openjdk.org/jdk/commit/89f5bacaf6ac6d5b3634db2fcde5b9abdc492b64
Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod
8309225: Fix xlc17 clang 15 warnings in security and servicability
Reviewed-by: goetz, mdoerr, clanger
-
PR: https://git.openjdk.org/jdk/pull/14282
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v9]
On Wed, 7 Jun 2023 07:54:17 GMT, Y. Srinivas Ramakrishna wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update copyright notices > > src/hotspot/share/gc/shenandoah/shenandoahFullGC.hpp line 3: > >> 1: /* >> 2: * Copyright (c) 2014, 2021, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > Unnecessary fixed. > src/hotspot/share/gc/shenandoah/shenandoahGC.cpp line 3: > >> 1: /* >> 2: * Copyright (c) 2021, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > Unnecessary fixed. > src/hotspot/share/gc/shenandoah/shenandoahGC.hpp line 3: > >> 1: /* >> 2: * Copyright (c) 2021, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > Unnecessary fixed. > src/hotspot/share/gc/shenandoah/shenandoahNMethod.cpp line 3: > >> 1: /* >> 2: * Copyright (c) 2019, 2022, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > Unnecessary? fixed. > src/hotspot/share/gc/shenandoah/shenandoahNumberSeq.hpp line 3: > >> 1: /* >> 2: * Copyright (c) 2018, 2019, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > Unnecessary? fixed. > src/hotspot/share/gc/shenandoah/shenandoahSTWMark.hpp line 3: > >> 1: /* >> 2: * Copyright (c) 2021, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > unnecessary. fixed. > src/hotspot/share/gc/shenandoah/shenandoahUnload.cpp line 3: > >> 1: /* >> 2: * Copyright (c) 2019, 2021, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > Delete fixed. > src/hotspot/share/gc/shenandoah/shenandoahWorkerPolicy.cpp line 3: > >> 1: /* >> 2: * Copyright (c) 2017, 2019, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > Unnecessary fixed. > src/hotspot/share/gc/shenandoah/shenandoahWorkerPolicy.hpp line 3: > >> 1: /* >> 2: * Copyright (c) 2017, 2022, Red Hat, Inc. All rights reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > Unnecessary fixed. > test/hotspot/gtest/gc/shenandoah/test_shenandoahNumberSeq.cpp line 2: > >> 1: /* >> 2: * Copyright (c) 2022, 2023, Oracle and/or its affiliates. All rights >> reserved. > > This may be deleted as far as I can tell, or we can just leave it in there. will leave as is. > test/hotspot/jtreg/gc/stress/gcold/TestGCOldWithShenandoah.java line 3: > >> 1: /* >> 2: * Copyright (c) 2016, 2020, Oracle and/or its affiliates. All rights >> reserved. >> 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > General comment: Looking at the history, I might have expected RedHat > copyright headers also for many of these tests, but that isn't a change > that's happened with generational shenandoah. So, nothing for us to do in > this PR. ok. will leave as is. - PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221595485 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221596525 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221597200 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221597834 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221598462 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221599944 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221599533 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221600615 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221601596 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221602442 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221604163
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v12]
> 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 > command line that already specifies ` -XX:+UseShenandoahGC`. The > implementation automatically adjusts the sizes of old generation and young > generation to efficiently utilize the entire heap capacity. Generational > mode of Shenandoah resembles G1 in the following regards: > > 1. Old-generation marking runs concurrently during the time that multiple > young generation collections run to completion. > 2. After old-generation marking completes, we perform a sequence of mixed > collections. Each mixed collection combines collection of young generation > with evacuation of a portion of the old-generation regions identified for > collection based on old-generation marking information. > 3. Unlike G1, young-generation collections and evacuations are entirely > concurrent, as with single-generation Shenandoah. > 4. As with single-generation Shenandoah, there is no explicit notion of eden > and survivor space within the young generation. In practice, regions that > were most recently allocated tend to have large amounts of garbage and these > regions tend to be collected with very little effort. Young-generation > objects that survive garbage collection tend to accumulate in regions that > hold survivor objects. These regions tend to have smaller amounts of > garbage, and are less likely to be collected. If they survive a sufficient > number of young-generation collections, the “survivor” regions are promoted > into the old generation. > > We expect to refine heuristics as we gain experience with more production > workloads. In the future, we plan to remove the “experimental” qualifier > from generational mode, at which time we expect that generational mode will > become the default mode for Shenandoah. > > **Testing**: We continuously run jtreg tiers 1-4 + hotspot_gc_shenandoah, > gcstress, jck compiler, jck runtime, Dacapo, SpecJBB, SpecVM, Extremem, > HyperAlloc, and multiple AWS production workload simulators. We test on Linux > x64 and aarch64, Alpine x64 and aarch64, macOS x64 and aarch64, and Windows > x64. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Remove more extraneous copyright notices - Changes: - all: https://git.openjdk.org/jdk/pull/14185/files - new: https://git.openjdk.org/jdk/pull/14185/files/88958669..8e5c3b73 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=14185=11 - incr: https://webrevs.openjdk.org/?repo=jdk=14185=10-11 Stats: 10 lines in 10 files changed: 0 ins; 10 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14185.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14185/head:pull/14185 PR: https://git.openjdk.org/jdk/pull/14185
Re: RFR: 8307153: JVMTI GetThreadState on carrier should return STATE_WAITING [v6]
On Wed, 7 Jun 2023 13:24:32 GMT, Alan Bateman wrote: >> Serguei Spitsyn has updated the pull request incrementally with one >> additional commit since the last revision: >> >> review: one function renaming > > src/hotspot/share/prims/jvmtiEnvBase.cpp line 1741: > >> 1739: "sanity check"); >> 1740: >> 1741: // An attempt to handshake-suspend a passive carrier thread will >> result in > > The rename from is_passive_carrier_thread to is_thread_carrying_vthread > looks fine. There are a few stray comments that still say "passive carrier > thread" that probably should be cleaned up. I see you've just integrated this > change but maybe the next change in the area that do this. Thanks. Alan. Will do this cleanup when there is a chance. - PR Review Comment: https://git.openjdk.org/jdk/pull/14298#discussion_r1221612240
Re: RFR: 8307153: JVMTI GetThreadState on carrier should return STATE_WAITING [v6]
On Wed, 7 Jun 2023 11:48:19 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_WAITING | JVMTI_THREAD_STATE_WAITING_INDEFINITELY. >> The fix adds: >> - a special case for passive carrier threads >> - necessary test coverage to the existing JVMTI test: >> `serviceability/jvmti/vthread/ThreadStateTest`. >> >> Testing: >>- tested with the updated test: >> `serviceability/jvmti/vthread/ThreadStateTest` >>- submitted mach5 tiers 1-5 >>- TBD: to submit mach5 tier 6 > > Serguei Spitsyn has updated the pull request incrementally with one > additional commit since the last revision: > > review: one function renaming src/hotspot/share/prims/jvmtiEnvBase.cpp line 1741: > 1739: "sanity check"); > 1740: > 1741: // An attempt to handshake-suspend a passive carrier thread will > result in The rename from is_passive_carrier_thread to is_thread_carrying_vthread looks fine. There are a few stray comments that still say "passive carrier thread" that probably should be cleaned up. I see you've just integrated this change but maybe the next change in the area that do this. - PR Review Comment: https://git.openjdk.org/jdk/pull/14298#discussion_r1221598356
Integrated: 8307153: JVMTI GetThreadState on carrier should return STATE_WAITING
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_WAITING | JVMTI_THREAD_STATE_WAITING_INDEFINITELY. > The fix adds: > - a special case for passive carrier threads > - necessary test coverage to the existing JVMTI test: > `serviceability/jvmti/vthread/ThreadStateTest`. > > Testing: >- tested with the updated test: > `serviceability/jvmti/vthread/ThreadStateTest` >- submitted mach5 tiers 1-5 >- TBD: to submit mach5 tier 6 This pull request has now been integrated. Changeset: 177e8327 Author:Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/177e8327d685444d63235567f2a9bde0ec3d51cf Stats: 82 lines in 4 files changed: 65 ins; 0 del; 17 mod 8307153: JVMTI GetThreadState on carrier should return STATE_WAITING Reviewed-by: amenkov, cjplummer - PR: https://git.openjdk.org/jdk/pull/14298
Re: RFR: 8309602: update JVMTI history table for jdk 21 [v2]
On Wed, 7 Jun 2023 12:56:18 GMT, Alan Bateman wrote: >> Serguei Spitsyn has updated the pull request incrementally with one >> additional commit since the last revision: >> >> review: simplified the latest history entries > > src/hotspot/share/prims/jvmti.xml line 15474: > >> 15472: Virtual threads finalized to be a permanent feature. >> 15473: Agent start-up in the live phase now specified to print a >> warning. >> 15474: > > This is just the history text, no normative changes, shouldn't need a CSR. Okay, thanks. Updated the description. - PR Review Comment: https://git.openjdk.org/jdk/pull/14352#discussion_r1221564482
Re: RFR: 8309602: update JVMTI history table for jdk 21 [v2]
On Wed, 7 Jun 2023 12:55:27 GMT, Alan Bateman wrote: >> Serguei Spitsyn has updated the pull request incrementally with one >> additional commit since the last revision: >> >> review: simplified the latest history entries > > src/hotspot/share/prims/jvmti.xml line 15459: > >> 15457: >> 15458: >> 15459: Preview feature - Support for virtual threads: > > Maybe "Support for virtual threads as preview feature" or "Support for > Virtual Threads (Preview)". Thanks. Fixed now. - PR Review Comment: https://git.openjdk.org/jdk/pull/14352#discussion_r1221558022
Re: RFR: 8309602: update JVMTI history table for jdk 21 [v3]
> This is a minor update of the `jvmti.xml` file. > The JVM TI history table needs to be updated to list: > - Virtual threads finalized to be a permanent feature. > - Agent start-up in the live phase now specified to print a warning. > > The JVM TI history table is maintained for convenience only and does not > require a CSR. Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: minor history table tweak - Changes: - all: https://git.openjdk.org/jdk/pull/14352/files - new: https://git.openjdk.org/jdk/pull/14352/files/a9e4f8eb..11db4f4f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=14352=02 - incr: https://webrevs.openjdk.org/?repo=jdk=14352=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14352.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14352/head:pull/14352 PR: https://git.openjdk.org/jdk/pull/14352
Re: RFR: 8309602: update JVMTI history table for jdk 21 [v2]
On Wed, 7 Jun 2023 12:57:34 GMT, Serguei Spitsyn wrote: >> This is a minor update of the `jvmti.xml` file. >> The JVM TI history table needs to be updated to list: >> - Virtual threads finalized to be a permanent feature. >> - Agent start-up in the live phase now specified to print a warning. >> >> The JVM TI history table is maintained for convenience only and does not >> require a CSR. > > Serguei Spitsyn has updated the pull request incrementally with one > additional commit since the last revision: > > review: simplified the latest history entries A small suggestion for the 19.0.0 note, otherwise good. src/hotspot/share/prims/jvmti.xml line 15459: > 15457: > 15458: > 15459: Preview feature - Support for virtual threads: Maybe "Support for virtual threads as preview feature" or "Support for Virtual Threads (Preview)". src/hotspot/share/prims/jvmti.xml line 15474: > 15472: Virtual threads finalized to be a permanent feature. > 15473: Agent start-up in the live phase now specified to print a > warning. > 15474: This is just the history text, no normative changes, shouldn't need a CSR. - Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14352#pullrequestreview-1467588938 PR Review Comment: https://git.openjdk.org/jdk/pull/14352#discussion_r1221548406 PR Review Comment: https://git.openjdk.org/jdk/pull/14352#discussion_r1221549609
Re: RFR: 8309602: update JVMTI history table for jdk 21 [v2]
> This is a minor update of the `jvmti.xml` file. > The JVM TI history table needs to be updated to list new capability, > functions and events added to support virtual threads as a permanent feature > in JDK 21. Also, it should list a minor update with the `Implementation Note` > that dynamic loading of agents into a running VM is now specified to print a > warning (JEP 451). > The JVM TI history table is maintained for convenience only and does not > require a CSR. Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: simplified the latest history entries - Changes: - all: https://git.openjdk.org/jdk/pull/14352/files - new: https://git.openjdk.org/jdk/pull/14352/files/cb95bf11..a9e4f8eb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=14352=01 - incr: https://webrevs.openjdk.org/?repo=jdk=14352=00-01 Stats: 15 lines in 1 file changed: 0 ins; 13 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14352.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14352/head:pull/14352 PR: https://git.openjdk.org/jdk/pull/14352
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v11]
> 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 > command line that already specifies ` -XX:+UseShenandoahGC`. The > implementation automatically adjusts the sizes of old generation and young > generation to efficiently utilize the entire heap capacity. Generational > mode of Shenandoah resembles G1 in the following regards: > > 1. Old-generation marking runs concurrently during the time that multiple > young generation collections run to completion. > 2. After old-generation marking completes, we perform a sequence of mixed > collections. Each mixed collection combines collection of young generation > with evacuation of a portion of the old-generation regions identified for > collection based on old-generation marking information. > 3. Unlike G1, young-generation collections and evacuations are entirely > concurrent, as with single-generation Shenandoah. > 4. As with single-generation Shenandoah, there is no explicit notion of eden > and survivor space within the young generation. In practice, regions that > were most recently allocated tend to have large amounts of garbage and these > regions tend to be collected with very little effort. Young-generation > objects that survive garbage collection tend to accumulate in regions that > hold survivor objects. These regions tend to have smaller amounts of > garbage, and are less likely to be collected. If they survive a sufficient > number of young-generation collections, the “survivor” regions are promoted > into the old generation. > > We expect to refine heuristics as we gain experience with more production > workloads. In the future, we plan to remove the “experimental” qualifier > from generational mode, at which time we expect that generational mode will > become the default mode for Shenandoah. > > **Testing**: We continuously run jtreg tiers 1-4 + hotspot_gc_shenandoah, > gcstress, jck compiler, jck runtime, Dacapo, SpecJBB, SpecVM, Extremem, > HyperAlloc, and multiple AWS production workload simulators. We test on Linux > x64 and aarch64, Alpine x64 and aarch64, macOS x64 and aarch64, and Windows > x64. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: JDK-8309322: [GenShen] TestAllocOutOfMemory#large failed When generational Shenandoah is used, there may be an additional alignment related heap size adjustment that the test should be cognizant of. Such alignment might also happen in the non-generational case, but in this case the specific size used in the test was affected on machines with larger than usual os page size settings. The alignment related adjustment would have affected all generational collectors (except perhaps Gen Z). In the future, we might try and relax this alignment constraint.alignment. - Changes: - all: https://git.openjdk.org/jdk/pull/14185/files - new: https://git.openjdk.org/jdk/pull/14185/files/221c88ff..88958669 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=14185=10 - incr: https://webrevs.openjdk.org/?repo=jdk=14185=09-10 Stats: 27 lines in 1 file changed: 16 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/14185.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14185/head:pull/14185 PR: https://git.openjdk.org/jdk/pull/14185
RFR: 8309602: update JVMTI history table for jdk 21
This is a minor update of the `jvmti.xml` file. The JVM TI history table needs to be updated to list new capability, functions and events added to support virtual threads as a permanent feature in JDK 21. Also, it should list a minor update with the `Implementation Note` that dynamic loading of agents into a running VM is now specified to print a warning (JEP 451). The JVM TI history table is maintained for convenience only and does not require a CSR. - Commit messages: - 8309602: update JVMTI history table for jdk 21 Changes: https://git.openjdk.org/jdk/pull/14352/files Webrev: https://webrevs.openjdk.org/?repo=jdk=14352=00 Issue: https://bugs.openjdk.org/browse/JDK-8309602 Stats: 18 lines in 1 file changed: 17 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14352.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14352/head:pull/14352 PR: https://git.openjdk.org/jdk/pull/14352
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v10]
> 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 > command line that already specifies ` -XX:+UseShenandoahGC`. The > implementation automatically adjusts the sizes of old generation and young > generation to efficiently utilize the entire heap capacity. Generational > mode of Shenandoah resembles G1 in the following regards: > > 1. Old-generation marking runs concurrently during the time that multiple > young generation collections run to completion. > 2. After old-generation marking completes, we perform a sequence of mixed > collections. Each mixed collection combines collection of young generation > with evacuation of a portion of the old-generation regions identified for > collection based on old-generation marking information. > 3. Unlike G1, young-generation collections and evacuations are entirely > concurrent, as with single-generation Shenandoah. > 4. As with single-generation Shenandoah, there is no explicit notion of eden > and survivor space within the young generation. In practice, regions that > were most recently allocated tend to have large amounts of garbage and these > regions tend to be collected with very little effort. Young-generation > objects that survive garbage collection tend to accumulate in regions that > hold survivor objects. These regions tend to have smaller amounts of > garbage, and are less likely to be collected. If they survive a sufficient > number of young-generation collections, the “survivor” regions are promoted > into the old generation. > > We expect to refine heuristics as we gain experience with more production > workloads. In the future, we plan to remove the “experimental” qualifier > from generational mode, at which time we expect that generational mode will > become the default mode for Shenandoah. > > **Testing**: We continuously run jtreg tiers 1-4 + hotspot_gc_shenandoah, > gcstress, jck compiler, jck runtime, Dacapo, SpecJBB, SpecVM, Extremem, > HyperAlloc, and multiple AWS production workload simulators. We test on Linux > x64 and aarch64, Alpine x64 and aarch64, macOS x64 and aarch64, and Windows > x64. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: Remove one more extraneous Amazon copyright - Changes: - all: https://git.openjdk.org/jdk/pull/14185/files - new: https://git.openjdk.org/jdk/pull/14185/files/f6c073a5..221c88ff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=14185=09 - incr: https://webrevs.openjdk.org/?repo=jdk=14185=08-09 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14185.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14185/head:pull/14185 PR: https://git.openjdk.org/jdk/pull/14185
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v9]
On Wed, 7 Jun 2023 07:22:13 GMT, Y. Srinivas Ramakrishna wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update copyright notices > > src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp line > 4: > >> 2: * Copyright (c) 2018, 2021, Red Hat, Inc. All rights reserved. >> 3: * Copyright (c) 2012, 2022 SAP SE. All rights reserved. >> 4: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. > > I believe line 4 should deleted; the copyright header change here is > unnecessary. will remove. I noticed that amazon had also contributed to this file, but changes were very minor. - PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221506981
Re: RFR: 8307153: JVMTI GetThreadState on carrier should return STATE_WAITING [v6]
On Wed, 7 Jun 2023 11:48:19 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_WAITING | JVMTI_THREAD_STATE_WAITING_INDEFINITELY. >> The fix adds: >> - a special case for passive carrier threads >> - necessary test coverage to the existing JVMTI test: >> `serviceability/jvmti/vthread/ThreadStateTest`. >> >> Testing: >>- tested with the updated test: >> `serviceability/jvmti/vthread/ThreadStateTest` >>- submitted mach5 tiers 1-5 >>- TBD: to submit mach5 tier 6 > > Serguei Spitsyn has updated the pull request incrementally with one > additional commit since the last revision: > > review: one function renaming Thank you for review, Alex and Chris. - PR Comment: https://git.openjdk.org/jdk/pull/14298#issuecomment-1580639648
Re: RFR: 8307153: JVMTI GetThreadState on carrier should return STATE_WAITING [v6]
> 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_WAITING | JVMTI_THREAD_STATE_WAITING_INDEFINITELY. > The fix adds: > - a special case for passive carrier threads > - necessary test coverage to the existing JVMTI test: > `serviceability/jvmti/vthread/ThreadStateTest`. > > Testing: >- tested with the updated test: > `serviceability/jvmti/vthread/ThreadStateTest` >- submitted mach5 tiers 1-5 >- TBD: to submit mach5 tier 6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: one function renaming - Changes: - all: https://git.openjdk.org/jdk/pull/14298/files - new: https://git.openjdk.org/jdk/pull/14298/files/3e7618c4..a6e6c981 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=14298=05 - incr: https://webrevs.openjdk.org/?repo=jdk=14298=04-05 Stats: 8 lines in 2 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/14298.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14298/head:pull/14298 PR: https://git.openjdk.org/jdk/pull/14298
Re: RFR: 8307153: JVMTI GetThreadState on carrier should return STATE_WAITING [v5]
On Wed, 7 Jun 2023 05:50:46 GMT, Alan Bateman wrote: >>> > is_carrying_carrier_thread? a bit artificial, but it's a carrier thread >>> > and it's carrying a virtual thread >>> >>> I guess, your suggestion is `is_carrying_virtual_thread`. Is it right? If >>> so, I like this suggestion. >> >> Up to you. I think any of this names is better than >> is_passive_carrier_thread. > >> I guess, your suggestion is `is_carrying_virtual_thread`. Is it right? If >> so, I like this suggestion. > > Good, I think will be easy to understand at the use sites. Thank you, Alan and Alex. - PR Review Comment: https://git.openjdk.org/jdk/pull/14298#discussion_r1221417248
Re: RFR: 8307153: JVMTI GetThreadState on carrier should return STATE_WAITING [v5]
> 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_WAITING | JVMTI_THREAD_STATE_WAITING_INDEFINITELY. > The fix adds: > - a special case for passive carrier threads > - necessary test coverage to the existing JVMTI test: > `serviceability/jvmti/vthread/ThreadStateTest`. > > Testing: >- tested with the updated test: > `serviceability/jvmti/vthread/ThreadStateTest` >- submitted mach5 tiers 1-5 >- TBD: to submit mach5 tier 6 Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge - review: call get_thread_state_base only when needed - review: removed JVMTI_THREAD_STATE_RUNNABLE from a carrier thread state - Merge - minor tweaks in libThreadStateTest.cpp - 8307153: JVMTI GetThreadState on carrier should return STATE_WAITING - Changes: - all: https://git.openjdk.org/jdk/pull/14298/files - new: https://git.openjdk.org/jdk/pull/14298/files/1816..3e7618c4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=14298=04 - incr: https://webrevs.openjdk.org/?repo=jdk=14298=03-04 Stats: 14603 lines in 141 files changed: 9240 ins; 4758 del; 605 mod Patch: https://git.openjdk.org/jdk/pull/14298.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14298/head:pull/14298 PR: https://git.openjdk.org/jdk/pull/14298
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v9]
On Wed, 7 Jun 2023 00:39:52 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:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational` to a >> command line that already specifies ` -XX:+UseShenandoahGC`. The >> implementation automatically adjusts the sizes of old generation and young >> generation to efficiently utilize the entire heap capacity. Generational >> mode of Shenandoah resembles G1 in the following regards: >> >> 1. Old-generation marking runs concurrently during the time that multiple >> young generation collections run to completion. >> 2. After old-generation marking completes, we perform a sequence of mixed >> collections. Each mixed collection combines collection of young generation >> with evacuation of a portion of the old-generation regions identified for >> collection based on old-generation marking information. >> 3. Unlike G1, young-generation collections and evacuations are entirely >> concurrent, as with single-generation Shenandoah. >> 4. As with single-generation Shenandoah, there is no explicit notion of eden >> and survivor space within the young generation. In practice, regions that >> were most recently allocated tend to have large amounts of garbage and these >> regions tend to be collected with very little effort. Young-generation >> objects that survive garbage collection tend to accumulate in regions that >> hold survivor objects. These regions tend to have smaller amounts of >> garbage, and are less likely to be collected. If they survive a sufficient >> number of young-generation collections, the “survivor” regions are promoted >> into the old generation. >> >> We expect to refine heuristics as we gain experience with more production >> workloads. In the future, we plan to remove the “experimental” qualifier >> from generational mode, at which time we expect that generational mode will >> become the default mode for Shenandoah. >> >> **Testing**: We continuously run jtreg tiers 1-4 + hotspot_gc_shenandoah, >> gcstress, jck compiler, jck runtime, Dacapo, SpecJBB, SpecVM, Extremem, >> HyperAlloc, and multiple AWS production workload simulators. We test on >> Linux x64 and aarch64, Alpine x64 and aarch64, macOS x64 and aarch64, and >> Windows x64. > > Kelvin Nilsen has updated the pull request incrementally with one additional > commit since the last revision: > > Update copyright notices test/hotspot/jtreg/gc/stress/gcold/TestGCOldWithShenandoah.java line 3: > 1: /* > 2: * Copyright (c) 2016, 2020, Oracle and/or its affiliates. All rights > reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. General comment: Looking at the history, I might have expected RedHat copyright headers also for many of these tests, but that isn't a change that's happened with generational shenandoah. So, nothing for us to do in this PR. - PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221136441
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v9]
On Wed, 7 Jun 2023 00:39:52 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:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational` to a >> command line that already specifies ` -XX:+UseShenandoahGC`. The >> implementation automatically adjusts the sizes of old generation and young >> generation to efficiently utilize the entire heap capacity. Generational >> mode of Shenandoah resembles G1 in the following regards: >> >> 1. Old-generation marking runs concurrently during the time that multiple >> young generation collections run to completion. >> 2. After old-generation marking completes, we perform a sequence of mixed >> collections. Each mixed collection combines collection of young generation >> with evacuation of a portion of the old-generation regions identified for >> collection based on old-generation marking information. >> 3. Unlike G1, young-generation collections and evacuations are entirely >> concurrent, as with single-generation Shenandoah. >> 4. As with single-generation Shenandoah, there is no explicit notion of eden >> and survivor space within the young generation. In practice, regions that >> were most recently allocated tend to have large amounts of garbage and these >> regions tend to be collected with very little effort. Young-generation >> objects that survive garbage collection tend to accumulate in regions that >> hold survivor objects. These regions tend to have smaller amounts of >> garbage, and are less likely to be collected. If they survive a sufficient >> number of young-generation collections, the “survivor” regions are promoted >> into the old generation. >> >> We expect to refine heuristics as we gain experience with more production >> workloads. In the future, we plan to remove the “experimental” qualifier >> from generational mode, at which time we expect that generational mode will >> become the default mode for Shenandoah. >> >> **Testing**: We continuously run jtreg tiers 1-4 + hotspot_gc_shenandoah, >> gcstress, jck compiler, jck runtime, Dacapo, SpecJBB, SpecVM, Extremem, >> HyperAlloc, and multiple AWS production workload simulators. We test on >> Linux x64 and aarch64, Alpine x64 and aarch64, macOS x64 and aarch64, and >> Windows x64. > > Kelvin Nilsen has updated the pull request incrementally with one additional > commit since the last revision: > > Update copyright notices test/hotspot/gtest/gc/shenandoah/test_shenandoahNumberSeq.cpp line 2: > 1: /* > 2: * Copyright (c) 2022, 2023, Oracle and/or its affiliates. All rights > reserved. This may be deleted as far as I can tell, or we can just leave it in there. - PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221124209
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v9]
On Wed, 7 Jun 2023 00:39:52 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:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational` to a >> command line that already specifies ` -XX:+UseShenandoahGC`. The >> implementation automatically adjusts the sizes of old generation and young >> generation to efficiently utilize the entire heap capacity. Generational >> mode of Shenandoah resembles G1 in the following regards: >> >> 1. Old-generation marking runs concurrently during the time that multiple >> young generation collections run to completion. >> 2. After old-generation marking completes, we perform a sequence of mixed >> collections. Each mixed collection combines collection of young generation >> with evacuation of a portion of the old-generation regions identified for >> collection based on old-generation marking information. >> 3. Unlike G1, young-generation collections and evacuations are entirely >> concurrent, as with single-generation Shenandoah. >> 4. As with single-generation Shenandoah, there is no explicit notion of eden >> and survivor space within the young generation. In practice, regions that >> were most recently allocated tend to have large amounts of garbage and these >> regions tend to be collected with very little effort. Young-generation >> objects that survive garbage collection tend to accumulate in regions that >> hold survivor objects. These regions tend to have smaller amounts of >> garbage, and are less likely to be collected. If they survive a sufficient >> number of young-generation collections, the “survivor” regions are promoted >> into the old generation. >> >> We expect to refine heuristics as we gain experience with more production >> workloads. In the future, we plan to remove the “experimental” qualifier >> from generational mode, at which time we expect that generational mode will >> become the default mode for Shenandoah. >> >> **Testing**: We continuously run jtreg tiers 1-4 + hotspot_gc_shenandoah, >> gcstress, jck compiler, jck runtime, Dacapo, SpecJBB, SpecVM, Extremem, >> HyperAlloc, and multiple AWS production workload simulators. We test on >> Linux x64 and aarch64, Alpine x64 and aarch64, macOS x64 and aarch64, and >> Windows x64. > > Kelvin Nilsen has updated the pull request incrementally with one additional > commit since the last revision: > > Update copyright notices src/hotspot/share/gc/shenandoah/shenandoahNMethod.cpp line 3: > 1: /* > 2: * Copyright (c) 2019, 2022, Red Hat, Inc. All rights reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Unnecessary? src/hotspot/share/gc/shenandoah/shenandoahNumberSeq.hpp line 3: > 1: /* > 2: * Copyright (c) 2018, 2019, Red Hat, Inc. All rights reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Unnecessary? src/hotspot/share/gc/shenandoah/shenandoahSTWMark.hpp line 3: > 1: /* > 2: * Copyright (c) 2021, Red Hat, Inc. All rights reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. unnecessary. src/hotspot/share/gc/shenandoah/shenandoahUnload.cpp line 3: > 1: /* > 2: * Copyright (c) 2019, 2021, Red Hat, Inc. All rights reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Delete src/hotspot/share/gc/shenandoah/shenandoahWorkerPolicy.cpp line 3: > 1: /* > 2: * Copyright (c) 2017, 2019, Red Hat, Inc. All rights reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Unnecessary src/hotspot/share/gc/shenandoah/shenandoahWorkerPolicy.hpp line 3: > 1: /* > 2: * Copyright (c) 2017, 2022, Red Hat, Inc. All rights reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Unnecessary - PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221104857 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221106767 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221110530 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221113191 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221115925 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221116941
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v9]
On Wed, 7 Jun 2023 00:39:52 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:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational` to a >> command line that already specifies ` -XX:+UseShenandoahGC`. The >> implementation automatically adjusts the sizes of old generation and young >> generation to efficiently utilize the entire heap capacity. Generational >> mode of Shenandoah resembles G1 in the following regards: >> >> 1. Old-generation marking runs concurrently during the time that multiple >> young generation collections run to completion. >> 2. After old-generation marking completes, we perform a sequence of mixed >> collections. Each mixed collection combines collection of young generation >> with evacuation of a portion of the old-generation regions identified for >> collection based on old-generation marking information. >> 3. Unlike G1, young-generation collections and evacuations are entirely >> concurrent, as with single-generation Shenandoah. >> 4. As with single-generation Shenandoah, there is no explicit notion of eden >> and survivor space within the young generation. In practice, regions that >> were most recently allocated tend to have large amounts of garbage and these >> regions tend to be collected with very little effort. Young-generation >> objects that survive garbage collection tend to accumulate in regions that >> hold survivor objects. These regions tend to have smaller amounts of >> garbage, and are less likely to be collected. If they survive a sufficient >> number of young-generation collections, the “survivor” regions are promoted >> into the old generation. >> >> We expect to refine heuristics as we gain experience with more production >> workloads. In the future, we plan to remove the “experimental” qualifier >> from generational mode, at which time we expect that generational mode will >> become the default mode for Shenandoah. >> >> **Testing**: We continuously run jtreg tiers 1-4 + hotspot_gc_shenandoah, >> gcstress, jck compiler, jck runtime, Dacapo, SpecJBB, SpecVM, Extremem, >> HyperAlloc, and multiple AWS production workload simulators. We test on >> Linux x64 and aarch64, Alpine x64 and aarch64, macOS x64 and aarch64, and >> Windows x64. > > Kelvin Nilsen has updated the pull request incrementally with one additional > commit since the last revision: > > Update copyright notices src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.hpp line 3: > 1: /* > 2: * Copyright (c) 2021, Red Hat, Inc. All rights reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Unnecessary. src/hotspot/share/gc/shenandoah/shenandoahFullGC.hpp line 3: > 1: /* > 2: * Copyright (c) 2014, 2021, Red Hat, Inc. All rights reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Unnecessary src/hotspot/share/gc/shenandoah/shenandoahGC.cpp line 3: > 1: /* > 2: * Copyright (c) 2021, Red Hat, Inc. All rights reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Unnecessary src/hotspot/share/gc/shenandoah/shenandoahGC.hpp line 3: > 1: /* > 2: * Copyright (c) 2021, Red Hat, Inc. All rights reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Unnecessary - PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221087455 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221091340 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221092320 PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221093246
Integrated: 8295976: GetThreadListStackTraces returns wrong state for blocked VirtualThread
On Tue, 6 Jun 2023 00:50:34 GMT, Serguei Spitsyn wrote: > The `GetThreadListStackTraces` returns `JVMTI_THREAD_STATE_RUNNABLE` for a > VirtualThread blocked on a monitor when called for more than one thread. When > called for a single VirtualThread it correctly returns a state that includes > the `JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER` flag. > The `VM_GetThreadListStackTraces::doit` should call the > `get_threadOop_and_JavaThread` instead of `cv_external_thread_to_JavaThread`. > But the `get_threadOop_and_JavaThread` has a check for the current thread by > comparing with the JavaThread::current() which does not work for a `VM_op`. > Some refactoring of the `get_threadOop_and_JavaThread` was made to make it > working for a `VM_op`. > Also, a minor bug in the `GetSingleStackTraceClosure::do_thread()` was > discovered during testing. > > The list of changes is: > - minor refactoring of the function`get_threadOop_and_JavaThread`: added an > overloaded version of this function with the extra parameter `JavaThread* > cur_thread`. It is called instead of > `JvmtiExport::cv_external_thread_to_JavaThread` from the > `VM_GetThreadListStackTraces::doit`. > - `GetSingleStackTraceClosure::do_thread()`: The use of `jt->threadObj()` is > replaced with the `JNIHandles::resolve_external_guard(_jthread)`. > - added new test to provide needed coverage: > `test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest` > > Testing: > - ran new test: > `test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest` > - TBD: tiers 1-6 (all are good) This pull request has now been integrated. Changeset: a25b7b8b Author:Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/a25b7b8b55f2dcd3c2945193d78f754580421733 Stats: 222 lines in 5 files changed: 215 ins; 2 del; 5 mod 8295976: GetThreadListStackTraces returns wrong state for blocked VirtualThread Reviewed-by: cjplummer, amenkov - PR: https://git.openjdk.org/jdk/pull/14326
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v9]
On Wed, 7 Jun 2023 00:39:52 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:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational` to a >> command line that already specifies ` -XX:+UseShenandoahGC`. The >> implementation automatically adjusts the sizes of old generation and young >> generation to efficiently utilize the entire heap capacity. Generational >> mode of Shenandoah resembles G1 in the following regards: >> >> 1. Old-generation marking runs concurrently during the time that multiple >> young generation collections run to completion. >> 2. After old-generation marking completes, we perform a sequence of mixed >> collections. Each mixed collection combines collection of young generation >> with evacuation of a portion of the old-generation regions identified for >> collection based on old-generation marking information. >> 3. Unlike G1, young-generation collections and evacuations are entirely >> concurrent, as with single-generation Shenandoah. >> 4. As with single-generation Shenandoah, there is no explicit notion of eden >> and survivor space within the young generation. In practice, regions that >> were most recently allocated tend to have large amounts of garbage and these >> regions tend to be collected with very little effort. Young-generation >> objects that survive garbage collection tend to accumulate in regions that >> hold survivor objects. These regions tend to have smaller amounts of >> garbage, and are less likely to be collected. If they survive a sufficient >> number of young-generation collections, the “survivor” regions are promoted >> into the old generation. >> >> We expect to refine heuristics as we gain experience with more production >> workloads. In the future, we plan to remove the “experimental” qualifier >> from generational mode, at which time we expect that generational mode will >> become the default mode for Shenandoah. >> >> **Testing**: We continuously run jtreg tiers 1-4 + hotspot_gc_shenandoah, >> gcstress, jck compiler, jck runtime, Dacapo, SpecJBB, SpecVM, Extremem, >> HyperAlloc, and multiple AWS production workload simulators. We test on >> Linux x64 and aarch64, Alpine x64 and aarch64, macOS x64 and aarch64, and >> Windows x64. > > Kelvin Nilsen has updated the pull request incrementally with one additional > commit since the last revision: > > Update copyright notices src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.hpp line 3: > 1: /* > 2: * Copyright (c) 2013, 2021, Red Hat, Inc. All rights reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Probably unnecessary. - PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221076190
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v9]
On Wed, 7 Jun 2023 00:39:52 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:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational` to a >> command line that already specifies ` -XX:+UseShenandoahGC`. The >> implementation automatically adjusts the sizes of old generation and young >> generation to efficiently utilize the entire heap capacity. Generational >> mode of Shenandoah resembles G1 in the following regards: >> >> 1. Old-generation marking runs concurrently during the time that multiple >> young generation collections run to completion. >> 2. After old-generation marking completes, we perform a sequence of mixed >> collections. Each mixed collection combines collection of young generation >> with evacuation of a portion of the old-generation regions identified for >> collection based on old-generation marking information. >> 3. Unlike G1, young-generation collections and evacuations are entirely >> concurrent, as with single-generation Shenandoah. >> 4. As with single-generation Shenandoah, there is no explicit notion of eden >> and survivor space within the young generation. In practice, regions that >> were most recently allocated tend to have large amounts of garbage and these >> regions tend to be collected with very little effort. Young-generation >> objects that survive garbage collection tend to accumulate in regions that >> hold survivor objects. These regions tend to have smaller amounts of >> garbage, and are less likely to be collected. If they survive a sufficient >> number of young-generation collections, the “survivor” regions are promoted >> into the old generation. >> >> We expect to refine heuristics as we gain experience with more production >> workloads. In the future, we plan to remove the “experimental” qualifier >> from generational mode, at which time we expect that generational mode will >> become the default mode for Shenandoah. >> >> **Testing**: We continuously run jtreg tiers 1-4 + hotspot_gc_shenandoah, >> gcstress, jck compiler, jck runtime, Dacapo, SpecJBB, SpecVM, Extremem, >> HyperAlloc, and multiple AWS production workload simulators. We test on >> Linux x64 and aarch64, Alpine x64 and aarch64, macOS x64 and aarch64, and >> Windows x64. > > Kelvin Nilsen has updated the pull request incrementally with one additional > commit since the last revision: > > Update copyright notices > Thanks Thomas for the feedback: > > These proposed changes represent improvements to both Generational and > Non-generational modes of operation. We can revert if that is desired, or we > can specialize Generational versions of these parameters so that they can > have different values in different modes, but here is a bit of background. > We've done considerable testing on a variety of synthetic workloads and some > limited testing on production workloads. As we move towards upstream > integration, we expect this will help us gain exposure to more production > workloads. The following changes were based on results of this testing: > Hi Kelvin, thanks for the thorough explanations! It is a pity that these valuable insights are buried in a GH discussion and these changes inside such a large patch. I also looked at the originating patch in openjdk/shenandoah, which I assume is your development repo for Shenandoah (?). Could I convince you to adapt the JBS issue process in the shenandoah repo (so, opening an issue on JBS, with some clear explanation, then fixing the bug)? Roman convinced me of this for the Lilliput repository, and now I think the added work is well worth it. JBS is a treasure trove of insights, if filled with care, and can help us for many years. Some more questions about `ShenandoahFullGCThreshold`: I am looking at the nice ASCII art in `ShenandoahControlThread::service_concurrent_normal_cycle`. IIUC, the cycle goes: Concurrent GC -> Alloc failure -> n x Degenerated GC -> Alloc Failure -> Full GC right? So the change is now in how often we try a degenerated GC before falling back to a full GC? With GenShen, does a degenerated GC still collect only the young regions? And only FullGC does collect all regions? Are comment and ASCII-art still correct for GenShen? E.g. the comment says: // If second allocation failure happens during Degenerated GC cycle (for example, when GC // tries to evac something and no memory is available), cycle degrades to Full GC. Is "second allocation failure" correct? Since even before this patch, we tried three times before falling back to a Full GC. Thank you, Thomas - PR Comment: https://git.openjdk.org/jdk/pull/14185#issuecomment-1580127311
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v9]
On Wed, 7 Jun 2023 00:39:52 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:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational` to a >> command line that already specifies ` -XX:+UseShenandoahGC`. The >> implementation automatically adjusts the sizes of old generation and young >> generation to efficiently utilize the entire heap capacity. Generational >> mode of Shenandoah resembles G1 in the following regards: >> >> 1. Old-generation marking runs concurrently during the time that multiple >> young generation collections run to completion. >> 2. After old-generation marking completes, we perform a sequence of mixed >> collections. Each mixed collection combines collection of young generation >> with evacuation of a portion of the old-generation regions identified for >> collection based on old-generation marking information. >> 3. Unlike G1, young-generation collections and evacuations are entirely >> concurrent, as with single-generation Shenandoah. >> 4. As with single-generation Shenandoah, there is no explicit notion of eden >> and survivor space within the young generation. In practice, regions that >> were most recently allocated tend to have large amounts of garbage and these >> regions tend to be collected with very little effort. Young-generation >> objects that survive garbage collection tend to accumulate in regions that >> hold survivor objects. These regions tend to have smaller amounts of >> garbage, and are less likely to be collected. If they survive a sufficient >> number of young-generation collections, the “survivor” regions are promoted >> into the old generation. >> >> We expect to refine heuristics as we gain experience with more production >> workloads. In the future, we plan to remove the “experimental” qualifier >> from generational mode, at which time we expect that generational mode will >> become the default mode for Shenandoah. >> >> **Testing**: We continuously run jtreg tiers 1-4 + hotspot_gc_shenandoah, >> gcstress, jck compiler, jck runtime, Dacapo, SpecJBB, SpecVM, Extremem, >> HyperAlloc, and multiple AWS production workload simulators. We test on >> Linux x64 and aarch64, Alpine x64 and aarch64, macOS x64 and aarch64, and >> Windows x64. > > Kelvin Nilsen has updated the pull request incrementally with one additional > commit since the last revision: > > Update copyright notices src/hotspot/share/gc/shenandoah/shenandoahBarrierSetClone.inline.hpp line 3: > 1: /* > 2: * Copyright (c) 2013, 2021, Red Hat, Inc. All rights reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Unnecessary. Delete. - PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221070505
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v9]
On Wed, 7 Jun 2023 00:39:52 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:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational` to a >> command line that already specifies ` -XX:+UseShenandoahGC`. The >> implementation automatically adjusts the sizes of old generation and young >> generation to efficiently utilize the entire heap capacity. Generational >> mode of Shenandoah resembles G1 in the following regards: >> >> 1. Old-generation marking runs concurrently during the time that multiple >> young generation collections run to completion. >> 2. After old-generation marking completes, we perform a sequence of mixed >> collections. Each mixed collection combines collection of young generation >> with evacuation of a portion of the old-generation regions identified for >> collection based on old-generation marking information. >> 3. Unlike G1, young-generation collections and evacuations are entirely >> concurrent, as with single-generation Shenandoah. >> 4. As with single-generation Shenandoah, there is no explicit notion of eden >> and survivor space within the young generation. In practice, regions that >> were most recently allocated tend to have large amounts of garbage and these >> regions tend to be collected with very little effort. Young-generation >> objects that survive garbage collection tend to accumulate in regions that >> hold survivor objects. These regions tend to have smaller amounts of >> garbage, and are less likely to be collected. If they survive a sufficient >> number of young-generation collections, the “survivor” regions are promoted >> into the old generation. >> >> We expect to refine heuristics as we gain experience with more production >> workloads. In the future, we plan to remove the “experimental” qualifier >> from generational mode, at which time we expect that generational mode will >> become the default mode for Shenandoah. >> >> **Testing**: We continuously run jtreg tiers 1-4 + hotspot_gc_shenandoah, >> gcstress, jck compiler, jck runtime, Dacapo, SpecJBB, SpecVM, Extremem, >> HyperAlloc, and multiple AWS production workload simulators. We test on >> Linux x64 and aarch64, Alpine x64 and aarch64, macOS x64 and aarch64, and >> Windows x64. > > Kelvin Nilsen has updated the pull request incrementally with one additional > commit since the last revision: > > Update copyright notices src/hotspot/cpu/riscv/gc/shenandoah/shenandoahBarrierSetAssembler_riscv.cpp line 4: > 2: * Copyright (c) 2018, 2020, Red Hat, Inc. All rights reserved. > 3: * Copyright (c) 2020, 2021, Huawei Technologies Co., Ltd. All rights > reserved. > 4: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Remove this line; extent of changes doesn't warrant copyright header change. src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.hpp line 3: > 1: /* > 2: * Copyright (c) 2018, 2021, Red Hat, Inc. All rights reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Should probably be removed. src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.hpp line 3: > 1: /* > 2: * Copyright (c) 2018, 2021, Red Hat, Inc. All rights reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Check if this is necessary. src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp line 4: > 2: * Copyright (c) 2015, 2021, Red Hat, Inc. All rights reserved. > 3: * Copyright (C) 2022 THL A29 Limited, a Tencent company. All rights > reserved. > 4: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Should be removed. src/hotspot/share/gc/shenandoah/heuristics/shenandoahCompactHeuristics.hpp line 3: > 1: /* > 2: * Copyright (c) 2018, 2019, Red Hat, Inc. All rights reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Can be removed? src/hotspot/share/gc/shenandoah/heuristics/shenandoahPassiveHeuristics.hpp line 3: > 1: /* > 2: * Copyright (c) 2018, 2019, Red Hat, Inc. All rights reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Should be removed? src/hotspot/share/gc/shenandoah/heuristics/shenandoahStaticHeuristics.hpp line 3: > 1: /* > 2: * Copyright (c) 2018, 2019, Red Hat, Inc. All rights reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Should be removed? src/hotspot/share/gc/shenandoah/mode/shenandoahPassiveMode.hpp line 3: > 1: /* > 2: * Copyright (c) 2019, Red Hat, Inc. All rights reserved. > 3: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. Should be removed? src/hotspot/share/gc/shenandoah/mode/shenandoahSATBMode.cpp line 3: > 1: /* > 2: * Copyright (c) 2019, 2021, Red Hat, Inc. All rights reserved. > 3: *
Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v9]
On Wed, 7 Jun 2023 00:39:52 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:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational` to a >> command line that already specifies ` -XX:+UseShenandoahGC`. The >> implementation automatically adjusts the sizes of old generation and young >> generation to efficiently utilize the entire heap capacity. Generational >> mode of Shenandoah resembles G1 in the following regards: >> >> 1. Old-generation marking runs concurrently during the time that multiple >> young generation collections run to completion. >> 2. After old-generation marking completes, we perform a sequence of mixed >> collections. Each mixed collection combines collection of young generation >> with evacuation of a portion of the old-generation regions identified for >> collection based on old-generation marking information. >> 3. Unlike G1, young-generation collections and evacuations are entirely >> concurrent, as with single-generation Shenandoah. >> 4. As with single-generation Shenandoah, there is no explicit notion of eden >> and survivor space within the young generation. In practice, regions that >> were most recently allocated tend to have large amounts of garbage and these >> regions tend to be collected with very little effort. Young-generation >> objects that survive garbage collection tend to accumulate in regions that >> hold survivor objects. These regions tend to have smaller amounts of >> garbage, and are less likely to be collected. If they survive a sufficient >> number of young-generation collections, the “survivor” regions are promoted >> into the old generation. >> >> We expect to refine heuristics as we gain experience with more production >> workloads. In the future, we plan to remove the “experimental” qualifier >> from generational mode, at which time we expect that generational mode will >> become the default mode for Shenandoah. >> >> **Testing**: We continuously run jtreg tiers 1-4 + hotspot_gc_shenandoah, >> gcstress, jck compiler, jck runtime, Dacapo, SpecJBB, SpecVM, Extremem, >> HyperAlloc, and multiple AWS production workload simulators. We test on >> Linux x64 and aarch64, Alpine x64 and aarch64, macOS x64 and aarch64, and >> Windows x64. > > Kelvin Nilsen has updated the pull request incrementally with one additional > commit since the last revision: > > Update copyright notices src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp line 4: > 2: * Copyright (c) 2018, 2021, Red Hat, Inc. All rights reserved. > 3: * Copyright (c) 2012, 2022 SAP SE. All rights reserved. > 4: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. I believe line 4 should deleted; the copyright header change here is unnecessary. - PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221032491
Re: RFR: 8308286 Fix clang warnings in linux code [v4]
On Thu, 1 Jun 2023 15:01:37 GMT, Artem Semenov wrote: >> When using the clang compiler to build OpenJDk on Linux, we encounter >> various "warnings as errors". >> They can be fixed with small changes. > > Artem Semenov has updated the pull request incrementally with one additional > commit since the last revision: > > update Marked as reviewed by avu (Committer). The latest changes look good to me. - PR Review: https://git.openjdk.org/jdk/pull/14033#pullrequestreview-1466776433 PR Comment: https://git.openjdk.org/jdk/pull/14033#issuecomment-1580043192
