From amenkov at openjdk.org  Thu Jun  1 00:57:10 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 1 Jun 2023 00:57:10 GMT
Subject: RFR: 8308978: regression with a deadlock involving
 FollowReferences [v3]
In-Reply-To: <lHmdoQHD3n7nh49mEXE4SS8-gI76h5kaItuMTXhwa3c=.35873b7c-1977-43e3-a6b8-ef563fb66c75@github.com>
References: <2J1qItzUgmfjRPS0xUbHgXZQ-b12JBxe8XPRftU2GyA=.025e7855-5df4-413a-bea7-585a53832025@github.com>
 <6xcKqU3mLr9TocEUpoXXzcNWSnKijSlhcyxIfXXrFD0=.2987b8de-827e-43d0-907b-7ef2016ddab4@github.com>
 <bNruEeFTCcLALuig4Asjz8E5zDYNXq6IZkjbYdnz0c0=.c287b302-c316-4e7b-9047-8d20559b332f@github.com>
 <lHmdoQHD3n7nh49mEXE4SS8-gI76h5kaItuMTXhwa3c=.35873b7c-1977-43e3-a6b8-ef563fb66c75@github.com>
Message-ID: <jxrcYvCTDadzn8zcCqwhdUC6hfHkF1RfPbODogIQp8o=.07e095b5-c688-4b03-a8cf-d4532309b806@github.com>

On Wed, 31 May 2023 22:57:08 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> > Something went wrong after 1st merge, testing failed with OOMEInAQS (which is problem-listed)
> 
> How do you run tests? Do you run tiers 1-5 or something else as well? Please, remember that the tier-5 runs the needed SVC tests with `main.wrapper=virtual`.

tier1-tier5 as per David's request
initial fix (before the test were problem-listed) was tested with JTREG_TEST_THREAD_FACTORY=Virtual

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

PR Comment: https://git.openjdk.org/jdk/pull/14233#issuecomment-1571154252

From david.holmes at oracle.com  Thu Jun  1 01:56:00 2023
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 1 Jun 2023 11:56:00 +1000
Subject: Clarifying jmethodID Usage and Potential JVM Crashes
In-Reply-To: <CAPb8aJ5K_1yk0FwTZOt_vzTXppB_=w5zK3guT6MDu6mpxeVRQA@mail.gmail.com>
References: <CAPb8aJ5K_1yk0FwTZOt_vzTXppB_=w5zK3guT6MDu6mpxeVRQA@mail.gmail.com>
Message-ID: <31e606ae-f54e-c8e6-c00b-720ef192d279@oracle.com>

Hi Jaroslav,

On 31/05/2023 9:12 pm, Jaroslav Bachor?k wrote:
> Dear Team,
> 
> I've been investigating the unusual JVM crashes occurring in JVMTI calls 
> on a J9 JVM. During my investigation, I scrutinized the `jmethodID` 
> definition closely, available here: [jmethodID 
> definition](https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#jmethodID <https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#jmethodID>).
> 
> To paraphrase, the definition suggests that `jmethodID` identifies a 
> Java method, initializer, or constructor. These identifiers, once 
> returned by JVM TI functions and events, can be safely stored. However, 
> when the class is unloaded, they become invalid, rendering them 
> unsuitable for use.
> 
> My interpretation is that the JVMTI user should verify the validity of a 
> `jmethodID` value before using it to prevent potential crashes. Would 
> you agree with this interpretation?

Not quite - as you note you can't verify the jmethodID validity. What 
the user needs to do, in line with what Dan was saying, is ensure that 
they keep track of the classes to which the methods belong and keep them 
alive if necessary. Now that may be easier said than done, but that is 
the gist of it. This comes from the JNI spec:

"A field or method ID does not prevent the VM from unloading the class 
from which the ID has been derived. After the class is unloaded, the 
method or field ID becomes invalid and may not be passed to any function 
taking such an ID. The native code, therefore, must make sure to:

     keep a live reference to the underlying class, or
     recompute the method or field ID

if it intends to use a method or field ID for an extended period of time."

> This sounds like a sensible requirement, but its practical application 
> remains unclear. As far as I know, methods can be unloaded concurrently 
> to the native code executing JVMTI functions. This introduces a 
> potential race condition where the JVM unloads the methods during the 
> check->use flow, making it only a partial solution. To complicate 
> matters further, no method exists to confirm whether a `jmethodID` is valid.
> 
> Theoretically, we could monitor the `CompiledMethodUnload` event to 
> track the validity state, creating a constantly expanding set of 
> unloaded `jmethodID` values or a bloom filter, if one does not care 
> about few potential false positives. This strategy, however, doesn't 
> address the potential race condition, and it could even exacerbate it 
> due to possible event delays. This delay might mistakenly validate a 
> `jmethodID` value that has already been unloaded, but for which the 
> event hasn't been delivered yet.
> 
> Honestly, I don't see a way to use `jmethodID` safely unless the code 
> using it suspends the entire JVM and doesn't resume until it's finished 
> with that `jmethodID`. Any other approach might lead to JVM crashes, as 
> we've observed with J9.
> 
> Lastly, it's noteworthy that Hotspot takes meticulous measures to ensure 
> that using jmethodIDs for unloaded methods doesn't crash the JVM and 
> even provides useful information. This observation has led me to 
> question whether the documentation aligns with the Hotspot 
> implementation, especially given that following closely the 
> documentation appears to increase the risk associated with the use of 
> `jmethodID` values.

There have been folk who wanted to make this area more user-friendly but 
that shouldn't be mistaken for moving towards a world where jmethodIDs 
are always safe to use.

Cheers,
David

> I welcome your thoughts and perspectives on this matter.
> 
> Best regards,
> 
> Jaroslav

From dholmes at openjdk.org  Thu Jun  1 02:12:05 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 1 Jun 2023 02:12:05 GMT
Subject: RFR: 8304438: jcmd JVMTI.agent_load should obey
 EnableDynamicAgentLoading [v3]
In-Reply-To: <SuKybfixTCm3WLfYJC99C226u_LIeXHFBmRE1Xcne_k=.2ec883df-c5de-47fa-b27e-79955e16978f@github.com>
References: <9H36lIpFiwG4v0oGPE2zCIawMJcNIhuGguz--qxjRnQ=.0fc08ed3-2d12-42d0-8b6c-3fa801d55427@github.com>
 <SuKybfixTCm3WLfYJC99C226u_LIeXHFBmRE1Xcne_k=.2ec883df-c5de-47fa-b27e-79955e16978f@github.com>
Message-ID: <S1YydpnQudiZZQq7VicV3FRUjYb_GJbXFFWFTQmznrk=.0cff34e6-2872-44cb-8b44-dbb3a3e9bc26@github.com>

On Wed, 31 May 2023 23:39:19 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The VM option EnableDynamicAgentLoading was added in JDK 9, default true, to allow deployment to choose whether to allow agents to be loaded/started in the VM. The VM option does the right thing for tools using the Attach API but jcmd JVMTI.agent_load was missed. This should be fixed to disallow loading JVMTI agents when the EnableDynamicAgentLoading is false.
>> 
>> Testing:
>>  - run new test `test/jdk/sun/tools/jcmd/TestJcmdNoAgentLoad.java`
>>  - TBD: submit mach5 tiers 1-5 to make sure no new regressions are introduced
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move check for EnableDynamicAgentLoading to invoke_Agent_OnAttach

A change in behaviour like this requires a CSR request - the code has been doing the wrong thing for a long time now!

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

PR Comment: https://git.openjdk.org/jdk/pull/14244#issuecomment-1571218267

From dholmes at openjdk.org  Thu Jun  1 02:19:08 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 1 Jun 2023 02:19:08 GMT
Subject: RFR: 8308090: Add container tests for on-the-fly resource quota
 updates [v2]
In-Reply-To: <WwBB6c7YIkNIkVPmQFpqJjEGwfZtTGV0Guty90S15ys=.884557e0-be15-430f-b742-43d412a833d5@github.com>
References: <w8L1msIb1ImXE3bWx4ZLaX3mg4MH_shRsN3CObIb-Ew=.1841e10b-595a-4bbb-9368-68897e4306df@github.com>
 <wM_d0lw-QV0H7VsCiI0QdOM-PKynxEFgz6wOVSPoJAU=.72b784bf-3656-4551-a3c9-1c33eb748e28@github.com>
 <WwBB6c7YIkNIkVPmQFpqJjEGwfZtTGV0Guty90S15ys=.884557e0-be15-430f-b742-43d412a833d5@github.com>
Message-ID: <aKb5HPTm43u3yKnF6OJrji0gpEnZdLs3lbZdFvAmxi4=.0f12cf97-3875-4574-965d-cb55dc76102e@github.com>

On Wed, 31 May 2023 12:07:49 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Severin Gehwolf 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 three additional commits since the last revision:
>> 
>>  - Merge branch 'master' into jdk-8308090-tests-container-on-fly-updates
>>  - Fix whitespace
>>  - 8308090: Add container tests for on-the-fly resource quota updates
>
> Anyone willing to review this?

@jerboaa I can't really review the tests themselves but will run through our CI to see if they cause any problems. If not then they should be okay to add.

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

PR Comment: https://git.openjdk.org/jdk/pull/14090#issuecomment-1571223360

From sspitsyn at openjdk.org  Thu Jun  1 02:38:11 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 1 Jun 2023 02:38:11 GMT
Subject: RFR: 8307478: Implementation of Prepare to Restrict The Dynamic
 Loading of Agents [v7]
In-Reply-To: <URHOLOH7Ok5oqrPLNIPDCcIkFDamLfUS925pVaeXJbU=.d8dde362-1683-445d-affc-3967686edc44@github.com>
References: <MA536Tpr3slk80MYAPS3P9fAsy-QLDNZpvN2pNvUGLA=.e2960455-4580-46f7-992d-39f625dac8cc@github.com>
 <xdt_eg8sLus0HtEvEq-g48qnv35YPC4W2lVPkNhROzA=.bb971caf-819b-4a29-ace6-519dc0eea271@github.com>
 <URHOLOH7Ok5oqrPLNIPDCcIkFDamLfUS925pVaeXJbU=.d8dde362-1683-445d-affc-3967686edc44@github.com>
Message-ID: <0qOfnlOvT1jPGl7Z3pYdXX4rf7tweXmPdlpxbt3hsso=.caaa8df4-4529-4b4a-b66b-7babc078793c@github.com>

On Wed, 31 May 2023 20:04:04 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Alan Bateman 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 17 additional commits since the last revision:
>> 
>>  - Add impl note to document the XX option
>>  - Cleanup
>>  - Merge
>>  - Allow for warning to be skipped when same agent loaded a second/subsequent time
>>  - Merge
>>  - Tweak javadoc, update test to use more test infra
>>  - Merge
>>  - Merge
>>  - Refresh package description
>>  - Merge
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/09807c2a...2d9d5922
>
> src/hotspot/share/prims/jvmtiAgent.cpp line 512:
> 
>> 510: 
>> 511:   // Print warning if EnableDynamicAgentLoading not enabled on the command line
>> 512:   if (!FLAG_IS_CMDLINE(EnableDynamicAgentLoading) && !agent->is_instrument_lib() && !JvmtiAgentList::is_loaded(library)) {
> 
> While looking at some code related to this, I noticed a couple of typos in the pre-existing load_agent_from_executable() comment. See lines 265 ("cant't") and 268 (".&&"). Maybe you could clean them up.

Nit: I'd suggest to add dot at the end of comment at 511.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13899#discussion_r1212499408

From sspitsyn at openjdk.org  Thu Jun  1 03:16:04 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 1 Jun 2023 03:16:04 GMT
Subject: RFR: 8304438: jcmd JVMTI.agent_load should obey
 EnableDynamicAgentLoading [v3]
In-Reply-To: <S1YydpnQudiZZQq7VicV3FRUjYb_GJbXFFWFTQmznrk=.0cff34e6-2872-44cb-8b44-dbb3a3e9bc26@github.com>
References: <9H36lIpFiwG4v0oGPE2zCIawMJcNIhuGguz--qxjRnQ=.0fc08ed3-2d12-42d0-8b6c-3fa801d55427@github.com>
 <SuKybfixTCm3WLfYJC99C226u_LIeXHFBmRE1Xcne_k=.2ec883df-c5de-47fa-b27e-79955e16978f@github.com>
 <S1YydpnQudiZZQq7VicV3FRUjYb_GJbXFFWFTQmznrk=.0cff34e6-2872-44cb-8b44-dbb3a3e9bc26@github.com>
Message-ID: <nj4pQM207i-PjmCvrZwE_JGHID2eCwfLEcj0LP-e5lg=.ab227d20-91e3-4247-b88a-982811b9b672@github.com>

On Thu, 1 Jun 2023 02:09:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

> A change in behaviour like this requires a CSR request - the code has been doing the wrong thing for a long time now!

Thank you for the comment. It was not fully clear if a CSR is needed in this case.
Created CSR (it is listed in the PR description).

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

PR Comment: https://git.openjdk.org/jdk/pull/14244#issuecomment-1571263870

From sspitsyn at openjdk.org  Thu Jun  1 05:23:10 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 1 Jun 2023 05:23:10 GMT
Subject: RFR: 8307478: Implementation of Prepare to Restrict The Dynamic
 Loading of Agents [v7]
In-Reply-To: <URHOLOH7Ok5oqrPLNIPDCcIkFDamLfUS925pVaeXJbU=.d8dde362-1683-445d-affc-3967686edc44@github.com>
References: <MA536Tpr3slk80MYAPS3P9fAsy-QLDNZpvN2pNvUGLA=.e2960455-4580-46f7-992d-39f625dac8cc@github.com>
 <xdt_eg8sLus0HtEvEq-g48qnv35YPC4W2lVPkNhROzA=.bb971caf-819b-4a29-ace6-519dc0eea271@github.com>
 <URHOLOH7Ok5oqrPLNIPDCcIkFDamLfUS925pVaeXJbU=.d8dde362-1683-445d-affc-3967686edc44@github.com>
Message-ID: <foq7KydNaJJ38kVQ5FTfqJ8tJcCXWWfnwAfafhbHGYk=.1e849863-e75b-46b4-96de-0c5ad79b39c5@github.com>

On Wed, 31 May 2023 20:21:15 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Alan Bateman 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 17 additional commits since the last revision:
>> 
>>  - Add impl note to document the XX option
>>  - Cleanup
>>  - Merge
>>  - Allow for warning to be skipped when same agent loaded a second/subsequent time
>>  - Merge
>>  - Tweak javadoc, update test to use more test infra
>>  - Merge
>>  - Merge
>>  - Refresh package description
>>  - Merge
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/a3c18c96...2d9d5922
>
> src/hotspot/share/prims/jvmtiAgent.cpp line 512:
> 
>> 510: 
>> 511:   // Print warning if EnableDynamicAgentLoading not enabled on the command line
>> 512:   if (!FLAG_IS_CMDLINE(EnableDynamicAgentLoading) && !agent->is_instrument_lib() && !JvmtiAgentList::is_loaded(library)) {
> 
> The use of `!JvmtiAgentList::is_loaded(library)` here is a bit confusing. Isn't the library always already loaded by the time we get here (the assert below seems to imply that)? If so, wouldn't it already be in the list? If it's not in the list yet, perhaps a comment explaining why would be helpful here.

It looks like you are right.
There is also and assert at line 519:
`519   assert(agent->is_loaded(), "invariant");`

So, the agent has to be loaded if we got to the line 512.
Also, there is a statement at line 507 (before line 512):
`507    agent->set_os_lib(library);`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13899#discussion_r1212584288

From thartmann at openjdk.org  Thu Jun  1 05:26:21 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 1 Jun 2023 05:26:21 GMT
Subject: RFR: 8309044: Replace NULL with nullptr,
 final sweep of hotspot code [v2]
In-Reply-To: <PBfTk3H5Reg_JykZaFWInLjp2kSW53CpHouGQ_W7bQc=.851a150c-df49-4775-9ec8-8f3b0702c293@github.com>
References: <3FoMnGeBp8DqkpVb6YGXKxdPsgGz6ej-jrf2U2stVfU=.56a11e19-38dd-420a-a07d-3b025120f194@github.com>
 <PBfTk3H5Reg_JykZaFWInLjp2kSW53CpHouGQ_W7bQc=.851a150c-df49-4775-9ec8-8f3b0702c293@github.com>
Message-ID: <9RnqD_bbEcutUNcfw9elCwYbPS_7-JiHMn_9cVAmDxQ=.830877a3-eac8-4af9-9ac0-5244c37989fb@github.com>

On Tue, 30 May 2023 19:15:38 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> A final sweep of Hotspot to remove all re-added NULLs. With only 110 changes I'd appreciate if this was considered trivial.
>
> Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Align
>  - Suggestions

What's the plan now to prevent re-introducing `NULL`?

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

PR Comment: https://git.openjdk.org/jdk/pull/14198#issuecomment-1571360076

From alanb at openjdk.org  Thu Jun  1 05:55:08 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Jun 2023 05:55:08 GMT
Subject: RFR: 8307478: Implementation of Prepare to Restrict The Dynamic
 Loading of Agents [v7]
In-Reply-To: <foq7KydNaJJ38kVQ5FTfqJ8tJcCXWWfnwAfafhbHGYk=.1e849863-e75b-46b4-96de-0c5ad79b39c5@github.com>
References: <MA536Tpr3slk80MYAPS3P9fAsy-QLDNZpvN2pNvUGLA=.e2960455-4580-46f7-992d-39f625dac8cc@github.com>
 <xdt_eg8sLus0HtEvEq-g48qnv35YPC4W2lVPkNhROzA=.bb971caf-819b-4a29-ace6-519dc0eea271@github.com>
 <URHOLOH7Ok5oqrPLNIPDCcIkFDamLfUS925pVaeXJbU=.d8dde362-1683-445d-affc-3967686edc44@github.com>
 <foq7KydNaJJ38kVQ5FTfqJ8tJcCXWWfnwAfafhbHGYk=.1e849863-e75b-46b4-96de-0c5ad79b39c5@github.com>
Message-ID: <GfhGyWrM1enqEape9ckxOvRW8h2MzDVJ0Ewm36LveB8=.5802f604-eb82-426b-8e20-3c424d1d5e24@github.com>

On Thu, 1 Jun 2023 05:20:31 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiAgent.cpp line 512:
>> 
>>> 510: 
>>> 511:   // Print warning if EnableDynamicAgentLoading not enabled on the command line
>>> 512:   if (!FLAG_IS_CMDLINE(EnableDynamicAgentLoading) && !agent->is_instrument_lib() && !JvmtiAgentList::is_loaded(library)) {
>> 
>> The use of `!JvmtiAgentList::is_loaded(library)` here is a bit confusing. Isn't the library always already loaded by the time we get here (the assert below seems to imply that)? If so, wouldn't it already be in the list? If it's not in the list yet, perhaps a comment explaining why would be helpful here.
>
> It looks like you are right.
> There is also and assert at line 519:
> `519   assert(agent->is_loaded(), "invariant");`
> 
> So, the agent has to be loaded if we got to the line 512.
> Also, there is a statement at line 507 (before line 512):
> `507    agent->set_os_lib(library);`

> The use of `!JvmtiAgentList::is_loaded(library)` here is a bit confusing. Isn't the library always already loaded by the time we get here (the assert below seems to imply that)? 

JvmtiAgentList::load_agent creates the JvmtiAgent, attempts to load it, and adds it to the agent list if is succeeds. The test that you are looking is checking the list of already loaded agents. Maybe the function name "is_loaded" is the confusion here, maybe a better name is needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13899#discussion_r1212610098

From alanb at openjdk.org  Thu Jun  1 05:58:11 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Jun 2023 05:58:11 GMT
Subject: RFR: 8307478: Implementation of Prepare to Restrict The Dynamic
 Loading of Agents [v6]
In-Reply-To: <kEoY-D8dNp9g6twxGiND-qWiPyUKz7jodLBTUvv_k_Q=.e9867ed6-8d40-41ef-9855-f60bc6058f71@github.com>
References: <MA536Tpr3slk80MYAPS3P9fAsy-QLDNZpvN2pNvUGLA=.e2960455-4580-46f7-992d-39f625dac8cc@github.com>
 <JE8TuLsL8hX2pV-Uf-B7yDkk3TyySOi0vHFc9Mn7JoE=.17bd556c-277a-4028-ab83-34f19afa6ffe@github.com>
 <kEoY-D8dNp9g6twxGiND-qWiPyUKz7jodLBTUvv_k_Q=.e9867ed6-8d40-41ef-9855-f60bc6058f71@github.com>
Message-ID: <Jd6t9BCUGbJ3ZDA_QNriEnOIf98pBEyv6VZramTPExs=.74fe288c-ff50-4d6b-8c4b-27e8a7db919e@github.com>

On Wed, 31 May 2023 20:37:23 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Alan Bateman 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 14 additional commits since the last revision:
>> 
>>  - Allow for warning to be skipped when same agent loaded a second/subsequent time
>>  - Merge
>>  - Tweak javadoc, update test to use more test infra
>>  - Merge
>>  - Merge
>>  - Refresh package description
>>  - Merge
>>  - Tweak docs
>>  - Merge
>>  - Draft docs changes
>>  - ... and 4 more: https://git.openjdk.org/jdk/compare/5a6c8363...a6d3c23c
>
> src/hotspot/share/prims/jvmtiAgentList.cpp line 231:
> 
>> 229:        if (agent->is_static_lib() && agent->is_loaded()) {
>> 230:          return true;
>> 231:        }
> 
> This doesn't make sense to me. If  you pass in `null` for `os_lib`, then we return true if any loaded static lib is found. Is this an attempt to limit the warning to just the first static lib that is loaded? Also, why would `null` ever be passed in if there wasn't at least one static lib. Some clarify comments would be useful.

load_agent_from_executable has a comment to explain how statically linked agents are started, that's why it needs to use agent->is_static_lib().&& agent->is_loaded() here. There isn't currently a way to test this but there is other work going to support static builds so it might be possible to write some automated tests at that point.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13899#discussion_r1212613094

From alanb at openjdk.org  Thu Jun  1 06:10:11 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Jun 2023 06:10:11 GMT
Subject: RFR: 8307478: Implementation of Prepare to Restrict The Dynamic
 Loading of Agents [v4]
In-Reply-To: <lZu3FqW0XyEpo0xG52wunTbD2AZNLNDyb3bEJnTpgnw=.4c7b96e1-1e10-4e58-a895-7bef42dcff25@github.com>
References: <MA536Tpr3slk80MYAPS3P9fAsy-QLDNZpvN2pNvUGLA=.e2960455-4580-46f7-992d-39f625dac8cc@github.com>
 <53KwBsPMnp0w_Xz-YomWCF8XdmvtuJV_m_9k8gkPzZo=.5a8ffaca-156d-4010-97f9-690b19f7ec29@github.com>
 <hteGm1asXBwlX91l8uhZuql_MrzM2-DjtKG6UliHkZY=.b8cd5573-244a-48f3-822e-2f58cf065de9@github.com>
 <Nmsl5STzN42zHZ6s2W0G0ObUTY4TJz3_WaQEYd7un5Q=.76af3322-bc69-4998-9b4c-4363247e4eb2@github.com>
 <lZu3FqW0XyEpo0xG52wunTbD2AZNLNDyb3bEJnTpgnw=.4c7b96e1-1e10-4e58-a895-7bef42dcff25@github.com>
Message-ID: <iHjSf78EhfQ-HEP_C1-8yb1o_8xTye7qvrFfkJyt5bQ=.12549c0f-92dc-4fa3-b1d9-4c3c1f8ac9fb@github.com>

On Wed, 31 May 2023 22:13:08 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> We can't currently test `jcmd JVMTI.agent_load` with `-XX:-EnableDynamicAgentLoading` due to JDK-8304438. But this test is for warnings, not that dynamic loading is disallowed.
>
> @AlanBateman  @sspitsyn Can this be revisited now that JDK-8304438 is being worked on? Perhaps the changes to JDK-8304438 can include an update to this test, although it all depends on which is being pushed first.

The tests have different concerns. The test here is checking that warnings are printed or can be suppressed. Tests for -EnableDynamicAgentLoading are a different concern. I see Serguei is expanding test coverage as part of JDK-8304438 so I think we are good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13899#discussion_r1212624593

From dholmes at openjdk.org  Thu Jun  1 06:23:07 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 1 Jun 2023 06:23:07 GMT
Subject: RFR: 8308090: Add container tests for on-the-fly resource quota
 updates [v2]
In-Reply-To: <wM_d0lw-QV0H7VsCiI0QdOM-PKynxEFgz6wOVSPoJAU=.72b784bf-3656-4551-a3c9-1c33eb748e28@github.com>
References: <w8L1msIb1ImXE3bWx4ZLaX3mg4MH_shRsN3CObIb-Ew=.1841e10b-595a-4bbb-9368-68897e4306df@github.com>
 <wM_d0lw-QV0H7VsCiI0QdOM-PKynxEFgz6wOVSPoJAU=.72b784bf-3656-4551-a3c9-1c33eb748e28@github.com>
Message-ID: <iH6ENwf58gay_TnatWAuYvJedw8seybCywur_nbfWDY=.375e51f0-4b85-4dca-9dbb-5f4d4f109fe2@github.com>

On Tue, 23 May 2023 09:04:11 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review these test changes which implement automatic testing of container resource updates without JVM restart. Note that this merely tests container detection code handling this case. It doesn't do anything special for the JVM itself, though it might make sense to add some sanity checks should we detect certain limits changing. In another PR, though.
>> 
>> As to the test design, it works similar to the shared temp tests: Interact between the two containers by virtue of a shared filesystem `/tmp` and creating marker files there in order to make them cooperate. Note that the new test needs `podman` version `4.3.0` and better (`4.5` is current).
>> 
>> Testing:
>>  - [x] GHA
>>  - [x] Linux x86_64 container tests on cg v1 and cg v2 system
>>  - [x] Newly added tests on Linux x86_64 cg v1 and cg v2 (`podman` and `docker`)
>
> Severin Gehwolf 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-8308090-tests-container-on-fly-updates
>  - Fix whitespace
>  - 8308090: Add container tests for on-the-fly resource quota updates

These tests didn't fail but I couldn't properly validate the output as we don't seem to save the process stdout file.

But I guess these are okay.

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14090#pullrequestreview-1454663420

From sspitsyn at openjdk.org  Thu Jun  1 06:50:11 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 1 Jun 2023 06:50:11 GMT
Subject: RFR: 8307478: Implementation of Prepare to Restrict The Dynamic
 Loading of Agents [v7]
In-Reply-To: <GfhGyWrM1enqEape9ckxOvRW8h2MzDVJ0Ewm36LveB8=.5802f604-eb82-426b-8e20-3c424d1d5e24@github.com>
References: <MA536Tpr3slk80MYAPS3P9fAsy-QLDNZpvN2pNvUGLA=.e2960455-4580-46f7-992d-39f625dac8cc@github.com>
 <xdt_eg8sLus0HtEvEq-g48qnv35YPC4W2lVPkNhROzA=.bb971caf-819b-4a29-ace6-519dc0eea271@github.com>
 <URHOLOH7Ok5oqrPLNIPDCcIkFDamLfUS925pVaeXJbU=.d8dde362-1683-445d-affc-3967686edc44@github.com>
 <foq7KydNaJJ38kVQ5FTfqJ8tJcCXWWfnwAfafhbHGYk=.1e849863-e75b-46b4-96de-0c5ad79b39c5@github.com>
 <GfhGyWrM1enqEape9ckxOvRW8h2MzDVJ0Ewm36LveB8=.5802f604-eb82-426b-8e20-3c424d1d5e24@github.com>
Message-ID: <KF29GDPqfJtIy8BJn5XECCEqtAoxCXE4w6DGoPTXM8U=.23f4f501-d000-4739-a8db-11016166a3e5@github.com>

On Thu, 1 Jun 2023 05:51:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> It looks like you are right.
>> There is also and assert at line 519:
>> `519   assert(agent->is_loaded(), "invariant");`
>> 
>> So, the agent has to be loaded if we got to the line 512.
>> Also, there is a statement at line 507 (before line 512):
>> `507    agent->set_os_lib(library);`
>
>> The use of `!JvmtiAgentList::is_loaded(library)` here is a bit confusing. Isn't the library always already loaded by the time we get here (the assert below seems to imply that)? 
> 
> JvmtiAgentList::load_agent creates the JvmtiAgent, attempts to load it, and adds it to the agent list if is succeeds. The test that you are looking is checking the list of already loaded agents. Maybe the function name "is_loaded" is the confusion here, maybe a better name is needed.

I see the source of my confusion.
The function `invoke_Agent_OnAttach` is called from the `JvmtiAgent::load`.
But at the time of `invoke_Agent_OnAttach` the agent has not been added to the list yet.
It is added after the `JvmtiAgent::load` with the function `JvmtiAgentList::add`:

jint JvmtiAgentList::load_agent(const char* agent_name, const char* absParam,
                           const char* options, outputStream* st) {
  // The abs parameter should be "true" or "false"
  const bool is_absolute_path = (absParam != nullptr) && (strcmp(absParam, "true") == 0);
  JvmtiAgent* const agent = new JvmtiAgent(agent_name, options, is_absolute_path, /* dynamic agent */ true);
  if (agent->load(st)) {
    add(agent);
  . . .

Now I see the code is correct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13899#discussion_r1212665902

From jaroslav.bachorik at datadoghq.com  Thu Jun  1 07:16:38 2023
From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=)
Date: Thu, 1 Jun 2023 09:16:38 +0200
Subject: Clarifying jmethodID Usage and Potential JVM Crashes
In-Reply-To: <31e606ae-f54e-c8e6-c00b-720ef192d279@oracle.com>
References: <CAPb8aJ5K_1yk0FwTZOt_vzTXppB_=w5zK3guT6MDu6mpxeVRQA@mail.gmail.com>
 <31e606ae-f54e-c8e6-c00b-720ef192d279@oracle.com>
Message-ID: <CAPb8aJ5kwQBLusLw0BWQQ9MGinmfu-HRfoo1cfBAEcP9AoC=7Q@mail.gmail.com>

Hi David,

On Thu, Jun 1, 2023 at 3:56?AM David Holmes <david.holmes at oracle.com> wrote:

> Hi Jaroslav,
>
> On 31/05/2023 9:12 pm, Jaroslav Bachor?k wrote:
> > Dear Team,
> >
> > I've been investigating the unusual JVM crashes occurring in JVMTI calls
> > on a J9 JVM. During my investigation, I scrutinized the `jmethodID`
> > definition closely, available here: [jmethodID
> > definition](
> https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#jmethodID
> <https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#jmethodID
> >).
> >
> > To paraphrase, the definition suggests that `jmethodID` identifies a
> > Java method, initializer, or constructor. These identifiers, once
> > returned by JVM TI functions and events, can be safely stored. However,
> > when the class is unloaded, they become invalid, rendering them
> > unsuitable for use.
> >
> > My interpretation is that the JVMTI user should verify the validity of a
> > `jmethodID` value before using it to prevent potential crashes. Would
> > you agree with this interpretation?
>
> Not quite - as you note you can't verify the jmethodID validity. What
> the user needs to do, in line with what Dan was saying, is ensure that
> they keep track of the classes to which the methods belong and keep them
> alive if necessary. Now that may be easier said than done, but that is
> the gist of it. This comes from the JNI spec:
>
> "A field or method ID does not prevent the VM from unloading the class
> from which the ID has been derived. After the class is unloaded, the
> method or field ID becomes invalid and may not be passed to any function
> taking such an ID. The native code, therefore, must make sure to:
>
>      keep a live reference to the underlying class, or
>      recompute the method or field ID
>
> if it intends to use a method or field ID for an extended period of time."
>
> > This sounds like a sensible requirement, but its practical application
> > remains unclear. As far as I know, methods can be unloaded concurrently
> > to the native code executing JVMTI functions. This introduces a
> > potential race condition where the JVM unloads the methods during the
> > check->use flow, making it only a partial solution. To complicate
> > matters further, no method exists to confirm whether a `jmethodID` is
> valid.
> >
> > Theoretically, we could monitor the `CompiledMethodUnload` event to
> > track the validity state, creating a constantly expanding set of
> > unloaded `jmethodID` values or a bloom filter, if one does not care
> > about few potential false positives. This strategy, however, doesn't
> > address the potential race condition, and it could even exacerbate it
> > due to possible event delays. This delay might mistakenly validate a
> > `jmethodID` value that has already been unloaded, but for which the
> > event hasn't been delivered yet.
> >
> > Honestly, I don't see a way to use `jmethodID` safely unless the code
> > using it suspends the entire JVM and doesn't resume until it's finished
> > with that `jmethodID`. Any other approach might lead to JVM crashes, as
> > we've observed with J9.
> >
> > Lastly, it's noteworthy that Hotspot takes meticulous measures to ensure
> > that using jmethodIDs for unloaded methods doesn't crash the JVM and
> > even provides useful information. This observation has led me to
> > question whether the documentation aligns with the Hotspot
> > implementation, especially given that following closely the
> > documentation appears to increase the risk associated with the use of
> > `jmethodID` values.
>
> There have been folk who wanted to make this area more user-friendly but
> that shouldn't be mistaken for moving towards a world where jmethodIDs
> are always safe to use.
>

Yes, I see your point. Unfortunately, this confirms my worries that using
AsyncGetCallTrace (ASGCT) on a system strictly adhering to the JVMTI spec
of jmethoID is not really possible without risking random and quite
frequent crashes on systems with concurrent class unloading enabled.
FTR, ASGCT will record the stack trace as a list of frames, each one
containing the corresponding jmethodID value. Considering that the most
common usage of ASGCT is in a signal handler it makes it impossible to use
JVMTI calls to resolve the holder class and create a strong reference to
prevent it from being unloaded.
And even if this would be possible we would need to figure out when to
release the class reference when it is no more needed - and it is not
really clear how we could do that reliably, leaving us with the option of
holding the class references indefinitely or risking crashing JVM.

I want to emphasize that not being able to resolve additional details for a
jmethodID pointing to a method of an unloaded class is not an issue, as
long as the JVMTI call does not crash. I think that
https://bugs.openjdk.org/browse/JDK-8268364 did address exactly the problem
of concurrent class unloading causing races in the code that is checking
for validity of jmethodID and then using it.


Can this be summarize in a way that the user is not guaranteed to get any
additional information for an invalid jmethodID but it would be really nice
for JVM not to crash when jmethodID becomes invalid as there is no way for
the user to check for its validity in an atomic manner
- and yes, even calling GetMethodDeclaringClass in order to obtain the
class one could create a strong reference is a subject to racy behaviour so
it really can not be used as a workaround.

Cheers,

-JB-


>
> Cheers,
> David
>
> > I welcome your thoughts and perspectives on this matter.
> >
> > Best regards,
> >
> > Jaroslav
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20230601/353b6d13/attachment-0001.htm>

From sspitsyn at openjdk.org  Thu Jun  1 07:38:15 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 1 Jun 2023 07:38:15 GMT
Subject: RFR: 8307478: Implementation of Prepare to Restrict The Dynamic
 Loading of Agents [v7]
In-Reply-To: <xdt_eg8sLus0HtEvEq-g48qnv35YPC4W2lVPkNhROzA=.bb971caf-819b-4a29-ace6-519dc0eea271@github.com>
References: <MA536Tpr3slk80MYAPS3P9fAsy-QLDNZpvN2pNvUGLA=.e2960455-4580-46f7-992d-39f625dac8cc@github.com>
 <xdt_eg8sLus0HtEvEq-g48qnv35YPC4W2lVPkNhROzA=.bb971caf-819b-4a29-ace6-519dc0eea271@github.com>
Message-ID: <U9u8LBl4yuI8m_2kedG7PNPn2IMANP0NlB0hkHWSebU=.633341c0-b3a0-4cc9-b3ae-cdc939db4122@github.com>

On Wed, 31 May 2023 15:01:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation for JEP 451. There are two parts to this:
>> 
>> 1. A multi-line warning is printed when a JVM TI or Java agent is loaded into a running VM. For JVM TI, the message is printed to stderr from JvmtiAgent::load. For Java agents, it is printed to System.err (as that may be redirected) in the JPLIS (j.l.instrumentation) implementation. This part includes an update to the JVM TI spec and API docs to require the warning.
>> 
>> 2. If running with -Djdk.instrument.traceUsage or -Djdk.instrument.traceUsage=true, the calls to the Instrumentation API print a trace message and stack trace.
>> 
>> Testing: tier1-6
>
> Alan Bateman 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 17 additional commits since the last revision:
> 
>  - Add impl note to document the XX option
>  - Cleanup
>  - Merge
>  - Allow for warning to be skipped when same agent loaded a second/subsequent time
>  - Merge
>  - Tweak javadoc, update test to use more test infra
>  - Merge
>  - Merge
>  - Refresh package description
>  - Merge
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/381973e4...2d9d5922

The update looks good to me.
Posted one nit though.
Thanks,
Serguei

test/jdk/com/sun/tools/attach/warnings/DynamicLoadWarningTest.java line 67:

> 65: class DynamicLoadWarningTest {
> 66:     private static final String JVMTI_AGENT_WARNING = "WARNING: A JVM TI agent has been dynamically loaded";
> 67:     private static final String JAVA_AGENT_WARNING = "WARNING: A Java agent has been loaded dynamically";

Nit: The warnings can be unified to say "loaded dynamically" or "dynamically loaded" in the same order.
Of course, it also impacts the files: `src/hotspot/share/prims/jvmtiAgent.cpp` and `src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java`.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13899#pullrequestreview-1454785048
PR Review Comment: https://git.openjdk.org/jdk/pull/13899#discussion_r1212717874

From thomas.stuefe at gmail.com  Thu Jun  1 08:03:39 2023
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 1 Jun 2023 10:03:39 +0200
Subject: Clarifying jmethodID Usage and Potential JVM Crashes
In-Reply-To: <CAPb8aJ5kwQBLusLw0BWQQ9MGinmfu-HRfoo1cfBAEcP9AoC=7Q@mail.gmail.com>
References: <CAPb8aJ5K_1yk0FwTZOt_vzTXppB_=w5zK3guT6MDu6mpxeVRQA@mail.gmail.com>
 <31e606ae-f54e-c8e6-c00b-720ef192d279@oracle.com>
 <CAPb8aJ5kwQBLusLw0BWQQ9MGinmfu-HRfoo1cfBAEcP9AoC=7Q@mail.gmail.com>
Message-ID: <CAA-vtUzoTnDRO5-kFQ5EzLSTM2Sjh5G3p95qX=iQ+Trmuf_4vw@mail.gmail.com>

On Thu, Jun 1, 2023 at 9:17?AM Jaroslav Bachor?k <
jaroslav.bachorik at datadoghq.com> wrote:

> Hi David,
>
> On Thu, Jun 1, 2023 at 3:56?AM David Holmes <david.holmes at oracle.com>
> wrote:
>
>> Hi Jaroslav,
>>
>> On 31/05/2023 9:12 pm, Jaroslav Bachor?k wrote:
>> > Dear Team,
>> >
>> > I've been investigating the unusual JVM crashes occurring in JVMTI
>> calls
>> > on a J9 JVM. During my investigation, I scrutinized the `jmethodID`
>> > definition closely, available here: [jmethodID
>> > definition](
>> https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#jmethodID
>> <
>> https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#jmethodID
>> >).
>> >
>> > To paraphrase, the definition suggests that `jmethodID` identifies a
>> > Java method, initializer, or constructor. These identifiers, once
>> > returned by JVM TI functions and events, can be safely stored. However,
>> > when the class is unloaded, they become invalid, rendering them
>> > unsuitable for use.
>> >
>> > My interpretation is that the JVMTI user should verify the validity of
>> a
>> > `jmethodID` value before using it to prevent potential crashes. Would
>> > you agree with this interpretation?
>>
>> Not quite - as you note you can't verify the jmethodID validity. What
>> the user needs to do, in line with what Dan was saying, is ensure that
>> they keep track of the classes to which the methods belong and keep them
>> alive if necessary. Now that may be easier said than done, but that is
>> the gist of it. This comes from the JNI spec:
>>
>> "A field or method ID does not prevent the VM from unloading the class
>> from which the ID has been derived. After the class is unloaded, the
>> method or field ID becomes invalid and may not be passed to any function
>> taking such an ID. The native code, therefore, must make sure to:
>>
>>      keep a live reference to the underlying class, or
>>      recompute the method or field ID
>>
>> if it intends to use a method or field ID for an extended period of time."
>>
>> > This sounds like a sensible requirement, but its practical application
>> > remains unclear. As far as I know, methods can be unloaded concurrently
>> > to the native code executing JVMTI functions. This introduces a
>> > potential race condition where the JVM unloads the methods during the
>> > check->use flow, making it only a partial solution. To complicate
>> > matters further, no method exists to confirm whether a `jmethodID` is
>> valid.
>> >
>> > Theoretically, we could monitor the `CompiledMethodUnload` event to
>> > track the validity state, creating a constantly expanding set of
>> > unloaded `jmethodID` values or a bloom filter, if one does not care
>> > about few potential false positives. This strategy, however, doesn't
>> > address the potential race condition, and it could even exacerbate it
>> > due to possible event delays. This delay might mistakenly validate a
>> > `jmethodID` value that has already been unloaded, but for which the
>> > event hasn't been delivered yet.
>> >
>> > Honestly, I don't see a way to use `jmethodID` safely unless the code
>> > using it suspends the entire JVM and doesn't resume until it's finished
>> > with that `jmethodID`. Any other approach might lead to JVM crashes, as
>> > we've observed with J9.
>> >
>> > Lastly, it's noteworthy that Hotspot takes meticulous measures to
>> ensure
>> > that using jmethodIDs for unloaded methods doesn't crash the JVM and
>> > even provides useful information. This observation has led me to
>> > question whether the documentation aligns with the Hotspot
>> > implementation, especially given that following closely the
>> > documentation appears to increase the risk associated with the use of
>> > `jmethodID` values.
>>
>> There have been folk who wanted to make this area more user-friendly but
>> that shouldn't be mistaken for moving towards a world where jmethodIDs
>> are always safe to use.
>>
>
> Yes, I see your point. Unfortunately, this confirms my worries that using
> AsyncGetCallTrace (ASGCT) on a system strictly adhering to the JVMTI spec
> of jmethoID is not really possible without risking random and quite
> frequent crashes on systems with concurrent class unloading enabled.
> FTR, ASGCT will record the stack trace as a list of frames, each one
> containing the corresponding jmethodID value. Considering that the most
> common usage of ASGCT is in a signal handler it makes it impossible to use
> JVMTI calls to resolve the holder class and create a strong reference to
> prevent it from being unloaded.
> And even if this would be possible we would need to figure out when to
> release the class reference when it is no more needed - and it is not
> really clear how we could do that reliably, leaving us with the option of
> holding the class references indefinitely or risking crashing JVM.
>
> I want to emphasize that not being able to resolve additional details for
> a jmethodID pointing to a method of an unloaded class is not an issue, as
> long as the JVMTI call does not crash. I think that
> https://bugs.openjdk.org/browse/JDK-8268364 did address exactly the
> problem of concurrent class unloading causing races in the code that is
> checking for validity of jmethodID and then using it.
>
>
> Can this be summarize in a way that the user is not guaranteed to get any
> additional information for an invalid jmethodID but it would be really nice
> for JVM not to crash when jmethodID becomes invalid as there is no way for
> the user to check for its validity in an atomic manner
> - and yes, even calling GetMethodDeclaringClass in order to obtain the
> class one could create a strong reference is a subject to racy behaviour so
> it really can not be used as a workaround.
>
>
I wonder about this. Looking at https://bugs.openjdk.org/browse/JDK-8268364
, we zero out the JNI handle table for the CLD earlier during class
unloading. IIUC ClassLoaderData::unload() can run concurrently to
Method::checked_resolve_jmethod_id,
so could we still not end up in the same situation (resolving Method when
the JNI table slot had still been occupied, but dereferencing Method after
it was freed? Admittedly more rarely?

Freeing method would return it to metaspace, and it may or may not be
uncommitted so crashes would be intermittent and random.

This is a Coleen question :)

Cheers,
>
> -JB-
>
>
>>
>> Cheers,
>> David
>>
>> > I welcome your thoughts and perspectives on this matter.
>> >
>> > Best regards,
>> >
>> > Jaroslav
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20230601/27e7d8fa/attachment-0001.htm>

From sgehwolf at openjdk.org  Thu Jun  1 08:24:06 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 1 Jun 2023 08:24:06 GMT
Subject: RFR: 8308090: Add container tests for on-the-fly resource quota
 updates [v2]
In-Reply-To: <aKb5HPTm43u3yKnF6OJrji0gpEnZdLs3lbZdFvAmxi4=.0f12cf97-3875-4574-965d-cb55dc76102e@github.com>
References: <w8L1msIb1ImXE3bWx4ZLaX3mg4MH_shRsN3CObIb-Ew=.1841e10b-595a-4bbb-9368-68897e4306df@github.com>
 <wM_d0lw-QV0H7VsCiI0QdOM-PKynxEFgz6wOVSPoJAU=.72b784bf-3656-4551-a3c9-1c33eb748e28@github.com>
 <WwBB6c7YIkNIkVPmQFpqJjEGwfZtTGV0Guty90S15ys=.884557e0-be15-430f-b742-43d412a833d5@github.com>
 <aKb5HPTm43u3yKnF6OJrji0gpEnZdLs3lbZdFvAmxi4=.0f12cf97-3875-4574-965d-cb55dc76102e@github.com>
Message-ID: <OgGcVr4ZvTCJer_-l8x-HoSoRCp_Zd_xctAUPpGFWN8=.3c4a216c-b4c4-4753-943e-b14e9c08f686@github.com>

On Thu, 1 Jun 2023 02:16:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Anyone willing to review this?
>
> @jerboaa I can't really review the tests themselves but will run through our CI to see if they cause any problems. If not then they should be okay to add.

Thanks @dholmes-ora for running them through your CI.

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

PR Comment: https://git.openjdk.org/jdk/pull/14090#issuecomment-1571584032

From david.holmes at oracle.com  Thu Jun  1 08:28:50 2023
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 1 Jun 2023 18:28:50 +1000
Subject: Clarifying jmethodID Usage and Potential JVM Crashes
In-Reply-To: <CAPb8aJ5kwQBLusLw0BWQQ9MGinmfu-HRfoo1cfBAEcP9AoC=7Q@mail.gmail.com>
References: <CAPb8aJ5K_1yk0FwTZOt_vzTXppB_=w5zK3guT6MDu6mpxeVRQA@mail.gmail.com>
 <31e606ae-f54e-c8e6-c00b-720ef192d279@oracle.com>
 <CAPb8aJ5kwQBLusLw0BWQQ9MGinmfu-HRfoo1cfBAEcP9AoC=7Q@mail.gmail.com>
Message-ID: <e44d0811-76ca-aabe-c7df-08062e77d011@oracle.com>

On 1/06/2023 5:16 pm, Jaroslav Bachor?k wrote:
> Hi David,
> 
> On Thu, Jun 1, 2023 at 3:56?AM David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
>     Hi Jaroslav,
> 
>     On 31/05/2023 9:12 pm, Jaroslav Bachor?k wrote:
>      > Dear Team,
>      >
>      > I've been investigating the unusual JVM crashes occurring in
>     JVMTI calls
>      > on a J9 JVM. During my investigation, I scrutinized the `jmethodID`
>      > definition closely, available here: [jmethodID
>      >
>     definition](https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#jmethodID <https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#jmethodID> <https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#jmethodID <https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#jmethodID>>).
>      >
>      > To paraphrase, the definition suggests that `jmethodID` identifies a
>      > Java method, initializer, or constructor. These identifiers, once
>      > returned by JVM TI functions and events, can be safely stored.
>     However,
>      > when the class is unloaded, they become invalid, rendering them
>      > unsuitable for use.
>      >
>      > My interpretation is that the JVMTI user should verify the
>     validity of a
>      > `jmethodID` value before using it to prevent potential crashes.
>     Would
>      > you agree with this interpretation?
> 
>     Not quite - as you note you can't verify the jmethodID validity. What
>     the user needs to do, in line with what Dan was saying, is ensure that
>     they keep track of the classes to which the methods belong and keep
>     them
>     alive if necessary. Now that may be easier said than done, but that is
>     the gist of it. This comes from the JNI spec:
> 
>     "A field or method ID does not prevent the VM from unloading the class
>     from which the ID has been derived. After the class is unloaded, the
>     method or field ID becomes invalid and may not be passed to any
>     function
>     taking such an ID. The native code, therefore, must make sure to:
> 
>      ? ? ?keep a live reference to the underlying class, or
>      ? ? ?recompute the method or field ID
> 
>     if it intends to use a method or field ID for an extended period of
>     time."
> 
>      > This sounds like a sensible requirement, but its practical
>     application
>      > remains unclear. As far as I know, methods can be unloaded
>     concurrently
>      > to the native code executing JVMTI functions. This introduces a
>      > potential race condition where the JVM unloads the methods during
>     the
>      > check->use flow, making it only a partial solution. To complicate
>      > matters further, no method exists to confirm whether a
>     `jmethodID` is valid.
>      >
>      > Theoretically, we could monitor the `CompiledMethodUnload` event to
>      > track the validity state, creating a constantly expanding set of
>      > unloaded `jmethodID` values or a bloom filter, if one does not care
>      > about few potential false positives. This strategy, however, doesn't
>      > address the potential race condition, and it could even
>     exacerbate it
>      > due to possible event delays. This delay might mistakenly validate a
>      > `jmethodID` value that has already been unloaded, but for which the
>      > event hasn't been delivered yet.
>      >
>      > Honestly, I don't see a way to use `jmethodID` safely unless the
>     code
>      > using it suspends the entire JVM and doesn't resume until it's
>     finished
>      > with that `jmethodID`. Any other approach might lead to JVM
>     crashes, as
>      > we've observed with J9.
>      >
>      > Lastly, it's noteworthy that Hotspot takes meticulous measures to
>     ensure
>      > that using jmethodIDs for unloaded methods doesn't crash the JVM and
>      > even provides useful information. This observation has led me to
>      > question whether the documentation aligns with the Hotspot
>      > implementation, especially given that following closely the
>      > documentation appears to increase the risk associated with the
>     use of
>      > `jmethodID` values.
> 
>     There have been folk who wanted to make this area more user-friendly
>     but
>     that shouldn't be mistaken for moving towards a world where jmethodIDs
>     are always safe to use.
> 
> 
> Yes, I see your point. Unfortunately, this confirms my worries that 
> using AsyncGetCallTrace (ASGCT) on a system strictly adhering to the 
> JVMTI spec of jmethoID is not really possible without risking random and 
> quite frequent crashes on systems with concurrent class unloading enabled.
> FTR, ASGCT will record the stack trace as a list of frames, each one 
> containing?the corresponding jmethodID value. Considering that the most 
> common usage of ASGCT is in a signal handler it makes it impossible to 
> use JVMTI calls to resolve the holder class and create a strong 
> reference to prevent it from being unloaded.
> And even if this would be possible we would need to figure out when to 
> release the class reference when it is no more needed - and it is not 
> really clear how we could do that reliably, leaving us with the option 
> of holding the class references indefinitely or risking crashing JVM.

I would have to agree you cannot use jmethodID's for that purpose, not 
without also recording (and keeping-alive) the associated classes. As to 
when you would clear such references I can't say as I don't know how the 
ASGCT stack record would be used.

> I want to emphasize that not being able to resolve additional details 
> for a jmethodID pointing to a method of an unloaded class is not an 
> issue, as long as the JVMTI call does not crash. I think that 
> https://bugs.openjdk.org/browse/JDK-8268364 
> <https://bugs.openjdk.org/browse/JDK-8268364> did address exactly the 
> problem of concurrent class unloading causing races in the code that is 
> checking for validity of jmethodID and then using it.

Yes but internal to the JVMTI implementation. The basic null check that 
was used was found to be insufficient when used with ZGC and so we would 
crash more often than was considered reasonable. There is a quoted 
comment in the code in https://bugs.openjdk.org/browse/JDK-8268088:

   // These aren't deallocated and are going to look like a leak, but that's
   // needed because we can't really get rid of jmethodIDs because we don't
   // know when native code is going to stop using them. The spec says that
   // they're "invalid" but existing programs likely rely on their being
   // NULL after class unloading.

that kind of sums up the position of trying to accommodate "bad code" in 
a reasonable way.

> Can this be summarize in a way that the user is not guaranteed to get 
> any additional information for an invalid jmethodID but it would be 
> really nice for JVM not to crash when jmethodID becomes invalid as there 
> is no way for the user to check for its validity in an atomic manner
> - and yes, even calling GetMethodDeclaringClass in order to obtain the 
> class one could create a strong reference is a subject to racy behaviour 
> so it really can not be used as a workaround.

The only real solution IMO would be to encode jmethodIDs in a way that 
validity can be tracked and then have all JVMTI methods be able to check 
that validity and guarantee atomicity of the method such that the id 
can't become invalid whilst in use. Whether that is at all 
feasible/practical I do not know - but it sounds like a major effort to me.

Cheers,
David

> Cheers,
> 
> -JB-
> 
> 
>     Cheers,
>     David
> 
>      > I welcome your thoughts and perspectives on this matter.
>      >
>      > Best regards,
>      >
>      > Jaroslav
> 

From dchuyko at openjdk.org  Thu Jun  1 09:30:41 2023
From: dchuyko at openjdk.org (Dmitry Chuyko)
Date: Thu, 1 Jun 2023 09:30:41 GMT
Subject: RFR: 8309271: A way to align already compiled methods with compiler
 directives
Message-ID: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>

Compiler Control (https://openjdk.org/jeps/165) provides method-context dependent control of the JVM compilers (C1 and C2). The active directive stack is built from the directive files passed with the `-XX:CompilerDirectivesFile` diagnostic command-line option and the Compiler.add_directives diagnostic command. It is also possible to clear all directives or remove the top from the stack.

A matching directive will be applied at method compilation time when such compilation is started. If directives are added or changed, but compilation does not start, then the state of compiled methods doesn't correspond to the rules. This is not an error, and it happens in long running applications when directives are added or removed after compilation of methods that could be matched. For example, the user decides that C2 compilation needs to be disabled for some method due to a compiler bug, issues such a directive but this does not affect the application behavior. In such case, the target application needs to be restarted, and such an operation can have high costs and risks. Another goal is testing/debugging compilers.

It would be convenient to optionally reconcile at least existing matching nmethods to the current stack of compiler directives. Methods in general are often inlined, and this information is hard to track down.

Natural way to eliminate the discrepancy between the result of compilation and the broken rule is to discard the compilation result, i.e. deoptimization. Obviously there is a performance penalty, so it should be applied with care. Hot code will most likely be recompiled soon, as nothing happens to its hotness.

A new flag '`-d`' has beed introduced for some directives related to compile commands: `Compiler.add_directives`, `Compiler.remove_directives`, `Compiler.clear_directives`. The default behavior has not changed (no flag). If the new flag is present, the command scans already compiled methods and marks for deoptimization those methods that have any active non-default matching compiler directives. There is currently no distinction which directives are found. In particular, this means that if there are rules for inlining into some method, it will be deoptimized. On the other hand, if there are rules for a method and it was inlined, top-level methods won't be deoptimized, but this can be achieved by having rules for them.

In addition, a new diagnistic command `Compiler.replace_directives`, has been added for convenience. It's like a combination of `Compiler.clear_directives` and `Compiler.add_directives`. It supports the same new optional '-d' flag that marks both cleared and added methods for deoptimization.

The behavior of the '-d' flag is implemented in the new `CodeCache::mark_for_deoptimization_directives_matches` and `DirectivesStack::hasMatchingDirectives` methods.

`CompilerDirectivesDCMDTest` now checks add, remove and replace commands in two modes (default and '-d') and checks that '-d' flag causes deoptimization.

An alternative approach to the '-d' flag could be to have a special diagnostic command for deoptimization. It will get a list of method patterns and reuse the matcher, however this is not so trivial. Overall usage and effects will be similar but this is one more file format. The user will also need to monitor or query active directives in advance, e.g. to deoptimize all mentioned methods after clearing all directives.

An alternative approach for selection of deoptimized methods could be to track down all inlining dependencies. This may be similar to searching references to old methods, but it requires scanning all code blobs, which looks too expensive.

An alternative naming for the flag is welcome. The obvious '-f' ('force') unfortunately has a conflict. Other verbs can be 'update', 'refresh' or 'apply'. Deoptimization is just what's done to reconcile the state. It could be something else, like first compiling with a different compiler and then switching to that version. Although in the latter case, triggered compilation would be an essential detail.

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

Commit messages:
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Formatting
 - Formatting
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Merge branch 'openjdk:master' into compiler-directives-force-update
 - Correct arguments info for new commands
 - Update through de-optimization

Changes: https://git.openjdk.org/jdk/pull/14111/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14111&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309271
  Stats: 214 lines in 9 files changed: 194 ins; 0 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/14111.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14111/head:pull/14111

PR: https://git.openjdk.org/jdk/pull/14111

From aph at openjdk.org  Thu Jun  1 09:46:25 2023
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 1 Jun 2023 09:46:25 GMT
Subject: RFR: 8309044: Replace NULL with nullptr,
 final sweep of hotspot code [v2]
In-Reply-To: <DayDaiijFt7-A7aeOnzwjQgSzG7JcFEFUlKpVjOWnto=.8abd11fa-1905-459d-9651-3c9518b393bb@github.com>
References: <3FoMnGeBp8DqkpVb6YGXKxdPsgGz6ej-jrf2U2stVfU=.56a11e19-38dd-420a-a07d-3b025120f194@github.com>
 <DayDaiijFt7-A7aeOnzwjQgSzG7JcFEFUlKpVjOWnto=.8abd11fa-1905-459d-9651-3c9518b393bb@github.com>
Message-ID: <ypo0VwtAQwGvfLj3Bdi2E0xQOCVgFzbQjkfmh6F9ISM=.02e47611-3a3e-42d1-a592-c3cac12a4d8b@github.com>

On Tue, 30 May 2023 00:57:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Can we now poison NULL so it can't get reintroduced? Or would that potentially break standard headers?

I'm sure it would. Maybe some changes to Skara?

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

PR Comment: https://git.openjdk.org/jdk/pull/14198#issuecomment-1571706648

From jsjolen at openjdk.org  Thu Jun  1 09:54:26 2023
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 1 Jun 2023 09:54:26 GMT
Subject: RFR: 8309044: Replace NULL with nullptr,
 final sweep of hotspot code [v2]
In-Reply-To: <9RnqD_bbEcutUNcfw9elCwYbPS_7-JiHMn_9cVAmDxQ=.830877a3-eac8-4af9-9ac0-5244c37989fb@github.com>
References: <3FoMnGeBp8DqkpVb6YGXKxdPsgGz6ej-jrf2U2stVfU=.56a11e19-38dd-420a-a07d-3b025120f194@github.com>
 <PBfTk3H5Reg_JykZaFWInLjp2kSW53CpHouGQ_W7bQc=.851a150c-df49-4775-9ec8-8f3b0702c293@github.com>
 <9RnqD_bbEcutUNcfw9elCwYbPS_7-JiHMn_9cVAmDxQ=.830877a3-eac8-4af9-9ac0-5244c37989fb@github.com>
Message-ID: <2WGxhOHFo3u8TGyhklFPc-Ipml5HL8PO9aakXX9cgFA=.d8e6a4c6-2da5-4173-ac96-fa4088f25502@github.com>

On Thu, 1 Jun 2023 05:23:25 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> What's the plan now to prevent re-introducing `NULL`?

Hi Tobias. The only plan in place is social, the reviewers have to look out for it. I am however researching how to do this through machine. I'm currently researching ways of preventing any re-introductions by machine. These include poisoning the NULL macro by re-defining it and finding a tool which is capable of parsing C++ code which is yet to go through the pre-processor.

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

PR Comment: https://git.openjdk.org/jdk/pull/14198#issuecomment-1571722147

From dnsimon at openjdk.org  Thu Jun  1 10:16:24 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 1 Jun 2023 10:16:24 GMT
Subject: RFR: 8309044: Replace NULL with nullptr,
 final sweep of hotspot code [v2]
In-Reply-To: <PBfTk3H5Reg_JykZaFWInLjp2kSW53CpHouGQ_W7bQc=.851a150c-df49-4775-9ec8-8f3b0702c293@github.com>
References: <3FoMnGeBp8DqkpVb6YGXKxdPsgGz6ej-jrf2U2stVfU=.56a11e19-38dd-420a-a07d-3b025120f194@github.com>
 <PBfTk3H5Reg_JykZaFWInLjp2kSW53CpHouGQ_W7bQc=.851a150c-df49-4775-9ec8-8f3b0702c293@github.com>
Message-ID: <AeWms2XFZgs48UJoN2gM_aZfL-BSkOiFV9Y3pU1RcVo=.b831dd7c-699f-4870-bf27-988e8aefa8cc@github.com>

On Tue, 30 May 2023 19:15:38 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> A final sweep of Hotspot to remove all re-added NULLs. With only 110 changes I'd appreciate if this was considered trivial.
>
> Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Align
>  - Suggestions

It may be simpler to use simple grepping + an allow list. For example using [`ag`](https://github.com/ggreer/the_silver_searcher) and `grep` seems to catch the few remaining offenders:

> ag NULL src/hotspot/ --cpp | grep -v _NULL | grep -v NULL_ | grep -v -E '[A-Z]NULL' | grep -v -E '//.*NULL' | grep -v '"NULL"'
src/hotspot/cpu/ppc/macroAssembler_ppc.hpp:735:  void load_klass_check_null(Register dst, Register src, Label* is_null = NULL);
src/hotspot/cpu/ppc/stubGenerator_ppc.cpp:4700:    if (UnsafeCopyMemory::_table == NULL) {
src/hotspot/cpu/x86/jvmciCodeInstaller_x86.cpp:191:    if (nop == NULL) {
src/hotspot/cpu/riscv/codeBuffer_riscv.cpp:74:  if (cb->stubs()->maybe_expand_to_ensure_remaining(total_requested_size) && cb->blob() == NULL) {
src/hotspot/cpu/riscv/stubGenerator_riscv.cpp:4019:    if (UnsafeCopyMemory::_table == NULL) {
src/hotspot/cpu/riscv/stubGenerator_riscv.cpp:4077:    if (bs_nm != NULL) {
src/hotspot/cpu/aarch64/jvmciCodeInstaller_aarch64.cpp:125:  NativeCall* call = NULL;
src/hotspot/cpu/aarch64/jvmciCodeInstaller_aarch64.cpp:158:    if (nop == NULL) {
src/hotspot/share/jfr/dcmd/jfrDcmds.hpp:162:    JavaPermission p = {"java.lang.management.ManagementPermission", "monitor", NULL};
src/hotspot/share/jfr/dcmd/jfrDcmds.hpp:187:    JavaPermission p = {"java.lang.management.ManagementPermission", "monitor", NULL};
src/hotspot/share/include/jvm.h:423: * Find a class from a boot class loader. Returns NULL if class not found.
src/hotspot/share/prims/jvmtiAgent.cpp:375:  const jint err = (*on_load_entry)(&main_vm, const_cast<char*>(agent->options()), NULL);
src/hotspot/share/prims/whitebox.cpp:1885:  if (cp->cache() == NULL) {
src/hotspot/share/prims/whitebox.cpp:1894:  if (cp->cache() == NULL) {
src/hotspot/share/classfile/stringTable.hpp:150:  static oop init_shared_table(const DumpedInternedStrings* dumped_interned_strings) NOT_CDS_JAVA_HEAP_RETURN_(NULL);
src/hotspot/share/utilities/globalDefinitions_xlc.hpp:95:  #undef NULL
src/hotspot/share/utilities/globalDefinitions_xlc.hpp:96:  #define NULL 0L
src/hotspot/share/utilities/globalDefinitions_xlc.hpp:98:  #ifndef NULL
src/hotspot/share/utilities/globalDefinitions_xlc.hpp:99:    #define NULL 0
src/hotspot/share/cds/filemap.cpp:363:  assert(ent != NULL, "sanity");
src/hotspot/share/utilities/globalDefinitions_visCPP.hpp:65:#undef NULL
src/hotspot/share/utilities/globalDefinitions_visCPP.hpp:69:#define NULL 0LL
src/hotspot/share/utilities/globalDefinitions_visCPP.hpp:71:#ifndef NULL
src/hotspot/share/utilities/globalDefinitions_visCPP.hpp:72:#define NULL 0
src/hotspot/share/utilities/globalDefinitions.cpp:162:  static_assert(sizeof(NULL) == sizeof(char*), "NULL must be same size as pointer");
src/hotspot/share/adlc/output_c.cpp:279:  for (pipeline->_reslist.reset(); (resource = pipeline->_reslist.iter()) != NULL;) {
src/hotspot/share/adlc/output_c.cpp:305:  for (pipeline->_reslist.reset(); (resource = pipeline->_reslist.iter()) != NULL;) {
src/hotspot/share/adlc/output_c.cpp:368:  for (pipeline->_reslist.reset(); (resource = pipeline->_reslist.iter()) != NULL;) {
src/hotspot/share/adlc/output_c.cpp:393:  for (pipeline->_reslist.reset(); (resource = pipeline->_reslist.iter()) != NULL;) {
src/hotspot/share/adlc/output_c.cpp:1009:  for (_pipeline->_reslist.reset(); (resource = _pipeline->_reslist.iter()) != NULL;) {
src/hotspot/share/gc/x/xBarrierSet.inline.hpp:187:    return Raw::oop_arraycopy_in_heap(nullptr, 0, src, NULL, 0, dst, length);
src/hotspot/share/gc/x/xPageTable.inline.hpp:43:    if (entry != NULL && entry != _prev) {
src/hotspot/share/gc/x/xBarrier.cpp:242:  return NULL;
src/hotspot/share/oops/cpCache.cpp:888:  LogStream* log_stream = NULL;
src/hotspot/share/oops/cpCache.cpp:906:    assert(resolved_references->obj_at(appendix_index) == NULL, "init just once");
src/hotspot/share/oops/cpCache.cpp:914:  if (log_stream != NULL) {
src/hotspot/share/opto/runtime.cpp:491:  fields[TypeFunc::Parms+0] = NULL; // void
src/hotspot/share/jvmci/jvmciEnv.cpp:366:    if (ex != NULL) {

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

PR Comment: https://git.openjdk.org/jdk/pull/14198#issuecomment-1571756690

From aph at openjdk.org  Thu Jun  1 10:17:19 2023
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 1 Jun 2023 10:17:19 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental)
In-Reply-To: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
Message-ID: <k6Nwq2vnx2SJQI5yLfS_WLDBc9eZAM8v-ts7I-y5B4g=.802dd93b-3a72-406e-9a7d-6db9f9c1e5e4@github.com>

On Fri, 26 May 2023 20:46:29 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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.

src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp line 147:

> 145:       }
> 146: #endif
> 147:     }

This logic is so gnarly that it's very hard to review and maintain, and IMO it's dangerous.

The problem is that its correctness depends on exactly how registers are allocated in its caller. This needs restructuring so that the register allocation is defined in a single place then passed down to everyone who needs it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1212922771

From stefank at openjdk.org  Thu Jun  1 10:25:21 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 1 Jun 2023 10:25:21 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental)
In-Reply-To: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
Message-ID: <xm0flhnqe2E9BneRAuuKvqdFCE-JMGIbKKJ9rL1xo7o=.3fc52141-a58e-4bad-9d33-e4c521896613@github.com>

On Fri, 26 May 2023 20:46:29 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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.

I've looked at the shared code and it's really nice that you've managed to keep them to a minimum. I have one tiny nit that would be nice to fix.

src/hotspot/share/gc/shared/gcConfiguration.cpp line 88:

> 86:     }
> 87: #endif
> 88:     return NA;

You moved the order between Shenandoah and ZGC in `young_collector()`, so you should probably do the same here.

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

PR Review: https://git.openjdk.org/jdk/pull/14185#pullrequestreview-1455087651
PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1212919666

From mdoerr at openjdk.org  Thu Jun  1 12:18:19 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 1 Jun 2023 12:18:19 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental)
In-Reply-To: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
Message-ID: <jpxh4BWV3qIL825gPzqs5atQcW15MdbpRS1jluaC51A=.080c2545-2e01-4f22-8cd3-f607d19188de@github.com>

On Fri, 26 May 2023 20:46:29 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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.

Issues already reported to GenShen engineers:

gc/shenandoah/TestElasticTLAB.java#generational
#? Internal Error (src\hotspot\share\gc\shenandoah\shenandoahFreeSet.cpp:695), pid=23288, tid=23784
#? assert(size % CardTable::card_size_in_words() == 0) failed: size must be multiple of card table size, was 258

gc/stress/gcold/TestGCOldWithShenandoah.java#generational
#? Internal Error (src\hotspot\share\gc\shenandoah\heuristics\shenandoahOldHeuristics.cpp:82), pid=20828, tid=5836
#? assert(_old_generation->available() > old_evacuation_budget) failed: Cannot budget more than is available

gc/shenandoah/oom/TestAllocOutOfMemory.java#large
Execution failed: `main' threw exception: java.lang.RuntimeException: 'java.lang.OutOfMemoryError: Java heap space' missing from stdout/stderr
(Issue with 64k Pages)

gc/shenandoah/TestRetainObjects.java#no-tlab
gc/shenandoah/TestSieveObjects.java#no-tlab
Timeouts.

gc/shenandoah/TestAllocObjects.java#generational
gc/shenandoah/TestDynamicSoftMaxHeapSize.java#generational
#? Internal Error src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp:664), pid=18434, tid=29955
#? assert(is_global() || ShenandoahHeap::heap()->is_full_gc_in_progress() || (_used + _humongous_waste <= _affiliated_region_count * ShenandoahHeapRegion::region_size_bytes())) failed: used cannot exceed regions

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

PR Comment: https://git.openjdk.org/jdk/pull/14185#issuecomment-1571947174

From alanb at openjdk.org  Thu Jun  1 12:37:20 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Jun 2023 12:37:20 GMT
Subject: RFR: 8307478: Implementation of Prepare to Restrict The Dynamic
 Loading of Agents [v8]
In-Reply-To: <MA536Tpr3slk80MYAPS3P9fAsy-QLDNZpvN2pNvUGLA=.e2960455-4580-46f7-992d-39f625dac8cc@github.com>
References: <MA536Tpr3slk80MYAPS3P9fAsy-QLDNZpvN2pNvUGLA=.e2960455-4580-46f7-992d-39f625dac8cc@github.com>
Message-ID: <p9MSGJXheJQU5ZaZqzVfu_MN-J5fKbuTrP0SyUQuCkc=.9af25da9-0c08-4866-bde1-1831b23d8e63@github.com>

> This is the implementation for JEP 451. There are two parts to this:
> 
> 1. A multi-line warning is printed when a JVM TI or Java agent is loaded into a running VM. For JVM TI, the message is printed to stderr from JvmtiAgent::load. For Java agents, it is printed to System.err (as that may be redirected) in the JPLIS (j.l.instrumentation) implementation. This part includes an update to the JVM TI spec and API docs to require the warning.
> 
> 2. If running with -Djdk.instrument.traceUsage or -Djdk.instrument.traceUsage=true, the calls to the Instrumentation API print a trace message and stack trace.
> 
> Testing: tier1-6

Alan Bateman 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 19 additional commits since the last revision:

 - Split is_loaded, typos in comments
 - Merge
 - Add impl note to document the XX option
 - Cleanup
 - Merge
 - Allow for warning to be skipped when same agent loaded a second/subsequent time
 - Merge
 - Tweak javadoc, update test to use more test infra
 - Merge
 - Merge
 - ... and 9 more: https://git.openjdk.org/jdk/compare/eb72f87a...cbd9bb1d

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13899/files
  - new: https://git.openjdk.org/jdk/pull/13899/files/2d9d5922..cbd9bb1d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13899&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13899&range=06-07

  Stats: 2137 lines in 162 files changed: 788 ins; 840 del; 509 mod
  Patch: https://git.openjdk.org/jdk/pull/13899.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13899/head:pull/13899

PR: https://git.openjdk.org/jdk/pull/13899

From alanb at openjdk.org  Thu Jun  1 12:37:21 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Jun 2023 12:37:21 GMT
Subject: RFR: 8307478: Implementation of Prepare to Restrict The Dynamic
 Loading of Agents [v6]
In-Reply-To: <Jd6t9BCUGbJ3ZDA_QNriEnOIf98pBEyv6VZramTPExs=.74fe288c-ff50-4d6b-8c4b-27e8a7db919e@github.com>
References: <MA536Tpr3slk80MYAPS3P9fAsy-QLDNZpvN2pNvUGLA=.e2960455-4580-46f7-992d-39f625dac8cc@github.com>
 <JE8TuLsL8hX2pV-Uf-B7yDkk3TyySOi0vHFc9Mn7JoE=.17bd556c-277a-4028-ab83-34f19afa6ffe@github.com>
 <kEoY-D8dNp9g6twxGiND-qWiPyUKz7jodLBTUvv_k_Q=.e9867ed6-8d40-41ef-9855-f60bc6058f71@github.com>
 <Jd6t9BCUGbJ3ZDA_QNriEnOIf98pBEyv6VZramTPExs=.74fe288c-ff50-4d6b-8c4b-27e8a7db919e@github.com>
Message-ID: <K78lrYfrv9214tz5c8vD-1wNG9OWf6ht8ZFbZHDd59k=.dd092cec-8d26-44f4-ae14-ddc6b4ad2634@github.com>

On Thu, 1 Jun 2023 05:55:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiAgentList.cpp line 231:
>> 
>>> 229:        if (agent->is_static_lib() && agent->is_loaded()) {
>>> 230:          return true;
>>> 231:        }
>> 
>> This doesn't make sense to me. If  you pass in `null` for `os_lib`, then we return true if any loaded static lib is found. Is this an attempt to limit the warning to just the first static lib that is loaded? Also, why would `null` ever be passed in if there wasn't at least one static lib. Some clarify comments would be useful.
>
> load_agent_from_executable has a comment to explain how statically linked agents are started, that's why it needs to use agent->is_static_lib().&& agent->is_loaded() here. There isn't currently a way to test this but there is other work going to support static builds so it might be possible to write some automated tests at that point.

I've updated this so that is_loaded is split into one function to test if a statically linked agent is already loaded and another for agent libraries. That might be clearer to understand.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13899#discussion_r1213080073

From stuefe at openjdk.org  Thu Jun  1 13:01:21 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 1 Jun 2023 13:01:21 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental)
In-Reply-To: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
Message-ID: <vNqlswssijhb9RIkTvHXvbsSgJw78v-NAHB_NOmodKk=.0e0e2e5a-f198-4c94-b337-14c3f0b8e967@github.com>

On Fri, 26 May 2023 20:46:29 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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.

Hi Kevin,

First off, kudos. This is impressive work by you and your Amazon colleagues!

I have one particular worry, though, how to verify that this experimental feature does not cause regressions with traditional Shenandoah? 

The PR is massive (+18kloc) and targeted for JDK 21. Rampdown P1 is in a week. By all accounts, JDK 21 will be a massive release, so we will all have our hands full, fixing stuff and plugging holes.

Oracle did put the sources for the Generational ZGC beside the old sources, thereby somewhat guaranteeing traditional ZGC does not regress. Could we follow the same cautionary process here?

I am not a Shenandoah expert, but to me the new feature seems intertwined with normal code paths. It's difficult to ensure, via review, that traditional Shenandoah will not suffer regressions. So close to rampdown this is a bit scary.

The JEP mentions several "Risks and Assumptions", but it is unclear whether these risks also affect traditional Shenandoah.

Cheers, Thomas

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

PR Comment: https://git.openjdk.org/jdk/pull/14185#issuecomment-1572008074

From duke at openjdk.org  Thu Jun  1 13:11:26 2023
From: duke at openjdk.org (JoKern65)
Date: Thu, 1 Jun 2023 13:11:26 GMT
Subject: Withdrawn: JDK-8308288: Fix xlc17 clang warnings in shared code
In-Reply-To: <lNHo2PewF8t-2JtnoWdRVGVEMPgd5CvMrR1uc8ISTVw=.d0500da0-4f0c-4ef1-ba7b-63e38cb603f3@github.com>
References: <lNHo2PewF8t-2JtnoWdRVGVEMPgd5CvMrR1uc8ISTVw=.d0500da0-4f0c-4ef1-ba7b-63e38cb603f3@github.com>
Message-ID: <kc61yDMer50HrFEk55-xDCN85ZeKj3D0p4IeXJk89cM=.9d90fcb8-28a8-42b2-8078-f84cfc94d14a@github.com>

On Thu, 25 May 2023 09:14:14 GMT, JoKern65 <duke at openjdk.org> wrote:

> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors".
> Some of those are in shared codebase and could be addressed by small adjustments.
> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/14146

From duke at openjdk.org  Thu Jun  1 13:11:24 2023
From: duke at openjdk.org (JoKern65)
Date: Thu, 1 Jun 2023 13:11:24 GMT
Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2]
In-Reply-To: <DXI-Jv0XoZZiIRkrJtCOMFR_qOkm26JWAsmP6velqrY=.07c751e1-487a-48ea-bc1c-ad8c73eae3b1@github.com>
References: <lNHo2PewF8t-2JtnoWdRVGVEMPgd5CvMrR1uc8ISTVw=.d0500da0-4f0c-4ef1-ba7b-63e38cb603f3@github.com>
 <DXI-Jv0XoZZiIRkrJtCOMFR_qOkm26JWAsmP6velqrY=.07c751e1-487a-48ea-bc1c-ad8c73eae3b1@github.com>
Message-ID: <tp1fasJhXNuAzfgL4wGOA33z2aejI2mT1hGsOASoDKQ=.37145f46-e3d2-48b7-b6c3-3a673f81c34a@github.com>

On Fri, 26 May 2023 08:31:46 GMT, JoKern65 <duke at openjdk.org> wrote:

>> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors".
>> Some of those are in shared codebase and could be addressed by small adjustments.
>> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code.
>
> JoKern65 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   forgotton _

Hi,

As this PR is big and spans several components I split
off the java.base, java.desktop and the sercivability/security
issues  into extra JBS issues. 
https://bugs.openjdk.org/browse/JDK-8309219 Fix xlc17 clang 1.5 warnings in java.base
https://bugs.openjdk.org/browse/JDK-8309224 Fix xlc17 clang 1.5 warnings in java.desktop
https://bugs.openjdk.org/browse/JDK-8309225 Fix xlc17 clang 1.5 warnings in security and servicability
I?ll move the changes from this pull request into new pull requests.
I will incorporate the requested changes right in the new PRs.
I will reuse this issue 8308388 for the hotspot changes but come up
with a new, smaller PR.
@colleenp, I will move alloca.h to the globalDefinitions_xlc.hpp.
@prrace, I will come up with an identical PR for the client
files (java.desktop), but improve the comment as @kimbarrett proposed
@mbaesken, I will use AIX and take up some of the other fixes you proposed.

I guess we need to find a way to fix the issue with the malloc 
in globalDefinitions_xlc.hpp in the upcoming PR for hotspot.  

Thanks for your help so far!

Hi,

As this PR is big and spans several components I split
off the java.base, java.desktop and the sercivability/security
issues into extra JBS issues.
https://bugs.openjdk.org/browse/JDK-8309219 Fix xlc17 clang 1.5 warnings in java.base
https://bugs.openjdk.org/browse/JDK-8309224 Fix xlc17 clang 1.5 warnings in java.desktop
https://bugs.openjdk.org/browse/JDK-8309225 Fix xlc17 clang 1.5 warnings in security and servicability
I?ll move the changes from this pull request into new pull requests.
I will incorporate the requested changes right in the new PRs.
I will reuse this issue 8308388 for the hotspot changes but come up
with a new, smaller PR.
@colleenp, I will move alloca.h to the globalDefinitions_xlc.hpp.
@prrace, I will come up with an identical PR for the client
files (java.desktop), but improve the comment as @kimbarrett proposed
@MBaesken, I will use AIX and take up some of the other fixes you proposed.

I guess we need to find a way to fix the issue with the malloc
in globalDefinitions_xlc.hpp in the upcoming PR for hotspot.

Thanks for your help so far!

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

PR Comment: https://git.openjdk.org/jdk/pull/14146#issuecomment-1572023812
PR Comment: https://git.openjdk.org/jdk/pull/14146#issuecomment-1572024628

From stuefe at openjdk.org  Thu Jun  1 14:33:27 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 1 Jun 2023 14:33:27 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental)
In-Reply-To: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
Message-ID: <WuVIRjQQhANFoCsiipvCQd4wvKqSyMuYi5kuCA9dv70=.7f94f9a4-5653-4214-b411-9b32f58c7ed3@github.com>

On Fri, 26 May 2023 20:46:29 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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.

I did a first read through the tests to check if any test changes affect traditional Shenandoah. To see if regression tests for non-generational are unchanged.

All good, I did not find anything noteworthy.

test/hotspot/jtreg/gc/shenandoah/TestEvilSyncBug.java line 33:

> 31:  * @modules java.base/jdk.internal.misc
> 32:  *          java.management
> 33:  * @run driver/timeout=480 TestEvilSyncBug -XX:ShenandoahGCHeuristics=aggressive

Probably fine, but why this change to non-generational testing? Will aggressive heuristic sharpen the test?

test/hotspot/jtreg/gc/shenandoah/mxbeans/TestChurnNotifications.java line 169:

> 167: 
> 168:                     MemoryUsage before = getUsage(mapBefore);
> 169:                     MemoryUsage after = getUsage(mapAfter);

This also changes test logic for traditional Shenandoah, but its harmless. 
Nit: more precise would be to require "Young Gen" pool to only exist for -XX:ShenandoahGCMode=generational.

test/hotspot/jtreg/gc/shenandoah/oom/TestAllocOutOfMemory.java line 23:

> 21:  * questions.
> 22:  *
> 23:  */

Three tests folded into one, but it does not look like functionality changed for testing traditional Shenandoah. Okay.

test/hotspot/jtreg/gc/shenandoah/oom/TestAllocOutOfMemory.java line 92:

> 90:             expectFailure("-Xmx16m",
> 91:                           "-XX:+UnlockExperimentalVMOptions",
> 92:                           "-XX:+UseShenandoahGC",

Nit: should not need UnlockExperimentalVMOptions anymore.

test/hotspot/jtreg/gc/shenandoah/oom/TestClassLoaderLeak.java line 132:

> 130:              {{"iu"},           {"adaptive", "aggressive"}},
> 131:              {{"passive"},      {"passive"}},
> 132:              {{"generational"}, {"adaptive"}}

Curious, here and in similar places, why only test adaptive heuristic for generational, if we test satb with all variants?

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

PR Review: https://git.openjdk.org/jdk/pull/14185#pullrequestreview-1455490699
PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1213164085
PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1213232252
PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1213243280
PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1213242053
PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1213244749

From sspitsyn at openjdk.org  Thu Jun  1 14:43:14 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 1 Jun 2023 14:43:14 GMT
Subject: RFR: 8307478: Implementation of Prepare to Restrict The Dynamic
 Loading of Agents [v8]
In-Reply-To: <p9MSGJXheJQU5ZaZqzVfu_MN-J5fKbuTrP0SyUQuCkc=.9af25da9-0c08-4866-bde1-1831b23d8e63@github.com>
References: <MA536Tpr3slk80MYAPS3P9fAsy-QLDNZpvN2pNvUGLA=.e2960455-4580-46f7-992d-39f625dac8cc@github.com>
 <p9MSGJXheJQU5ZaZqzVfu_MN-J5fKbuTrP0SyUQuCkc=.9af25da9-0c08-4866-bde1-1831b23d8e63@github.com>
Message-ID: <Z2RTBCGkHyEdehSaCmyxWktKqVlmlAQoxisineInGGA=.e134f964-fcc2-4337-b9cc-9b82b0877efa@github.com>

On Thu, 1 Jun 2023 12:37:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation for JEP 451. There are two parts to this:
>> 
>> 1. A multi-line warning is printed when a JVM TI or Java agent is loaded into a running VM. For JVM TI, the message is printed to stderr from JvmtiAgent::load. For Java agents, it is printed to System.err (as that may be redirected) in the JPLIS (j.l.instrumentation) implementation. This part includes an update to the JVM TI spec and API docs to require the warning.
>> 
>> 2. If running with -Djdk.instrument.traceUsage or -Djdk.instrument.traceUsage=true, the calls to the Instrumentation API print a trace message and stack trace.
>> 
>> Testing: tier1-6
>
> Alan Bateman 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 19 additional commits since the last revision:
> 
>  - Split is_loaded, typos in comments
>  - Merge
>  - Add impl note to document the XX option
>  - Cleanup
>  - Merge
>  - Allow for warning to be skipped when same agent loaded a second/subsequent time
>  - Merge
>  - Tweak javadoc, update test to use more test infra
>  - Merge
>  - Merge
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/6cea493a...cbd9bb1d

The update looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13899#pullrequestreview-1455647274

From asemenov at openjdk.org  Thu Jun  1 15:01:37 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 1 Jun 2023 15:01:37 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v4]
In-Reply-To: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
Message-ID: <gMtRBStdo62ZscHEotlSWQ70g-EiN_wJGNLRY910KUw=.0b899a67-1cad-45f6-a7d8-d539f7cc8af1@github.com>

> 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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14033/files
  - new: https://git.openjdk.org/jdk/pull/14033/files/d5b70cb2..b423bd4c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=02-03

  Stats: 7 lines in 2 files changed: 1 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14033.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14033/head:pull/14033

PR: https://git.openjdk.org/jdk/pull/14033

From asemenov at openjdk.org  Thu Jun  1 15:07:11 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 1 Jun 2023 15:07:11 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v3]
In-Reply-To: <XCV9wPHhv83rnla_Y8LoBYJ9EdcQfuAlClsvp01vHdg=.d8982ce2-253e-4ba5-93f5-ca12c489c38b@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <CKiRtl0qFJAta3S3Ysa1wQHfQI34FDAW6qLvb8p336U=.2f3cfe22-b050-4483-b95b-b53aa8e2e78d@github.com>
 <XCV9wPHhv83rnla_Y8LoBYJ9EdcQfuAlClsvp01vHdg=.d8982ce2-253e-4ba5-93f5-ca12c489c38b@github.com>
Message-ID: <CnZGN1jj91T015K1ywlKfrv0xj-eRKVJMd2iayTSXWg=.a6386461-e844-480a-b351-901cfb945be5@github.com>

On Wed, 31 May 2023 13:52:39 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update
>
> src/java.security.jgss/share/native/libj2gss/gssapi.h line 47:
> 
>> 45: 
>> 46: // Condition was copied from
>> 47: // Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/gssapi/gssapi.h
> 
> In the current version of the file above, it's written as
> 
> #if defined(__APPLE__) && (defined(__ppc__) ||...
> 
> Is it better?

done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1213297788

From weijun at openjdk.org  Thu Jun  1 15:07:12 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 1 Jun 2023 15:07:12 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v3]
In-Reply-To: <CnZGN1jj91T015K1ywlKfrv0xj-eRKVJMd2iayTSXWg=.a6386461-e844-480a-b351-901cfb945be5@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <CKiRtl0qFJAta3S3Ysa1wQHfQI34FDAW6qLvb8p336U=.2f3cfe22-b050-4483-b95b-b53aa8e2e78d@github.com>
 <XCV9wPHhv83rnla_Y8LoBYJ9EdcQfuAlClsvp01vHdg=.d8982ce2-253e-4ba5-93f5-ca12c489c38b@github.com>
 <CnZGN1jj91T015K1ywlKfrv0xj-eRKVJMd2iayTSXWg=.a6386461-e844-480a-b351-901cfb945be5@github.com>
Message-ID: <A6_DjU6Oy1FQ2jv01AAzEvvtbwyIZzbqhrc-qG-Lfh8=.b6ee5527-f523-42b6-ae40-f7c14ee797f7@github.com>

On Thu, 1 Jun 2023 15:02:16 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> src/java.security.jgss/share/native/libj2gss/gssapi.h line 47:
>> 
>>> 45: 
>>> 46: // Condition was copied from
>>> 47: // Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/gssapi/gssapi.h
>> 
>> In the current version of the file above, it's written as
>> 
>> #if defined(__APPLE__) && (defined(__ppc__) ||...
>> 
>> Is it better?
>
> done

I didn't ask to revert the change. It's `s/TARGET_OS_MAC/defined(__APPLE__)/`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1213300305

From cjplummer at openjdk.org  Thu Jun  1 15:18:18 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 1 Jun 2023 15:18:18 GMT
Subject: RFR: 8307478: Implementation of Prepare to Restrict The Dynamic
 Loading of Agents [v7]
In-Reply-To: <KF29GDPqfJtIy8BJn5XECCEqtAoxCXE4w6DGoPTXM8U=.23f4f501-d000-4739-a8db-11016166a3e5@github.com>
References: <MA536Tpr3slk80MYAPS3P9fAsy-QLDNZpvN2pNvUGLA=.e2960455-4580-46f7-992d-39f625dac8cc@github.com>
 <xdt_eg8sLus0HtEvEq-g48qnv35YPC4W2lVPkNhROzA=.bb971caf-819b-4a29-ace6-519dc0eea271@github.com>
 <URHOLOH7Ok5oqrPLNIPDCcIkFDamLfUS925pVaeXJbU=.d8dde362-1683-445d-affc-3967686edc44@github.com>
 <foq7KydNaJJ38kVQ5FTfqJ8tJcCXWWfnwAfafhbHGYk=.1e849863-e75b-46b4-96de-0c5ad79b39c5@github.com>
 <GfhGyWrM1enqEape9ckxOvRW8h2MzDVJ0Ewm36LveB8=.5802f604-eb82-426b-8e20-3c424d1d5e24@github.com>
 <KF29GDPqfJtIy8BJn5XECCEqtAoxCXE4w6DGoPTXM8U=.23f4f501-d000-4739-a8db-11016166a3e5@github.com>
Message-ID: <g2BCDbXmGo2Ld9vgQNFLuuWB_o9jWLjp8R83ho3VJEg=.31e82308-2cc5-4b8d-8b40-a64d487c0b1d@github.com>

On Thu, 1 Jun 2023 06:46:41 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>>> The use of `!JvmtiAgentList::is_loaded(library)` here is a bit confusing. Isn't the library always already loaded by the time we get here (the assert below seems to imply that)? 
>> 
>> JvmtiAgentList::load_agent creates the JvmtiAgent, attempts to load it, and adds it to the agent list if is succeeds. The test that you are looking is checking the list of already loaded agents. Maybe the function name "is_loaded" is the confusion here, maybe a better name is needed.
>
> I see the source of my confusion.
> The function `invoke_Agent_OnAttach` is called from the `JvmtiAgent::load`.
> But at the time of `invoke_Agent_OnAttach` the agent has not been added to the list yet.
> It is added after the `JvmtiAgent::load` with the function `JvmtiAgentList::add`:
> 
> jint JvmtiAgentList::load_agent(const char* agent_name, const char* absParam,
>                            const char* options, outputStream* st) {
>   // The abs parameter should be "true" or "false"
>   const bool is_absolute_path = (absParam != nullptr) && (strcmp(absParam, "true") == 0);
>   JvmtiAgent* const agent = new JvmtiAgent(agent_name, options, is_absolute_path, /* dynamic agent */ true);
>   if (agent->load(st)) {
>     add(agent);
>   . . .
> 
> Now I see the code is correct.
> I'd suggest to add a small comment before the line 512 saying
> that the agent has not been included into the agents list yet.

> JvmtiAgentList::load_agent creates the JvmtiAgent, attempts to load it, and adds it to the agent list if is succeeds. The test that you are looking is checking the list of already loaded agents. Maybe the function name "is_loaded" is the confusion here, maybe a better name is needed.

Yes, I did notice that there were two different `is_loaded` checks going on. What's not clear is the relation between agent->is_loaded() and JvmtiAgentList::is_loaded(library). I assume that at this point in time the library is not on the list but the agent is loaded, so that's why it works, but it's not clear to me why this is the case. I think a comment here explaining why would be helpful so the reader doesn't need to track down when each of these "loaded" conditions becomes true.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13899#discussion_r1213314470

From cjplummer at openjdk.org  Thu Jun  1 15:27:12 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 1 Jun 2023 15:27:12 GMT
Subject: RFR: 8304438: jcmd JVMTI.agent_load should obey
 EnableDynamicAgentLoading [v2]
In-Reply-To: <uXvLeD6gVSY1R0nsd2xv2KUhp-hsC8quaPALOFuk_cY=.b35ec2be-edb1-4b2d-bf0f-56aa42f97081@github.com>
References: <9H36lIpFiwG4v0oGPE2zCIawMJcNIhuGguz--qxjRnQ=.0fc08ed3-2d12-42d0-8b6c-3fa801d55427@github.com>
 <uXvLeD6gVSY1R0nsd2xv2KUhp-hsC8quaPALOFuk_cY=.b35ec2be-edb1-4b2d-bf0f-56aa42f97081@github.com>
Message-ID: <TywHHGqhaYYEOLCJab4FFATxcxzDFvWr3Bm_GwZarvk=.c9f4360c-43ad-4d9b-909b-f47a36c52a97@github.com>

On Wed, 31 May 2023 10:30:22 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The VM option EnableDynamicAgentLoading was added in JDK 9, default true, to allow deployment to choose whether to allow agents to be loaded/started in the VM. The VM option does the right thing for tools using the Attach API but jcmd JVMTI.agent_load was missed. This should be fixed to disallow loading JVMTI agents when the EnableDynamicAgentLoading is false.
>> 
>> The CSR is:
>> [JDK-8309250](https://bugs.openjdk.org/browse/JDK-8309250): jcmd JVMTI.agent_load should obey EnableDynamicAgentLoading
>> 
>> Testing:
>>  - run new test `test/jdk/sun/tools/jcmd/TestJcmdNoAgentLoad.java`
>>  - TBD: submit mach5 tiers 1-5 to make sure no new regressions are introduced
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor renaming in new test TestJcmdNoAgentLoad.java

test/jdk/sun/tools/jcmd/TestJcmdNoAgentLoad.java line 68:

> 66:                 System.out.println("Found output line with the expected error message:\n" + line);
> 67:             }
> 68:         }

Why not just use  `OutputAnalyzer.shouldContain()`?

test/jdk/sun/tools/jcmd/TestJcmdNoAgentLoad.java line 70:

> 68:         }
> 69:         if (!seenPattern) {
> 70:             throw new RuntimeException("Not found expected error message in output");

"Not found" -> "Did not find"

Also, you should include the expected error message in the output.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14244#discussion_r1212367038
PR Review Comment: https://git.openjdk.org/jdk/pull/14244#discussion_r1212367594

From cjplummer at openjdk.org  Thu Jun  1 15:27:09 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 1 Jun 2023 15:27:09 GMT
Subject: RFR: 8304438: jcmd JVMTI.agent_load should obey
 EnableDynamicAgentLoading [v3]
In-Reply-To: <SuKybfixTCm3WLfYJC99C226u_LIeXHFBmRE1Xcne_k=.2ec883df-c5de-47fa-b27e-79955e16978f@github.com>
References: <9H36lIpFiwG4v0oGPE2zCIawMJcNIhuGguz--qxjRnQ=.0fc08ed3-2d12-42d0-8b6c-3fa801d55427@github.com>
 <SuKybfixTCm3WLfYJC99C226u_LIeXHFBmRE1Xcne_k=.2ec883df-c5de-47fa-b27e-79955e16978f@github.com>
Message-ID: <rA2B1S0Zo8aN3Slvt6TwxvrrxKA_jMl4_u3mR8HD3F0=.571e5a11-39a7-4f64-97b6-d1aa74f9c15e@github.com>

On Wed, 31 May 2023 23:39:19 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The VM option EnableDynamicAgentLoading was added in JDK 9, default true, to allow deployment to choose whether to allow agents to be loaded/started in the VM. The VM option does the right thing for tools using the Attach API but jcmd JVMTI.agent_load was missed. This should be fixed to disallow loading JVMTI agents when the EnableDynamicAgentLoading is false.
>> 
>> The CSR is:
>> [JDK-8309250](https://bugs.openjdk.org/browse/JDK-8309250): jcmd JVMTI.agent_load should obey EnableDynamicAgentLoading
>> 
>> Testing:
>>  - run new test `test/jdk/sun/tools/jcmd/TestJcmdNoAgentLoad.java`
>>  - TBD: submit mach5 tiers 1-5 to make sure no new regressions are introduced
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move check for EnableDynamicAgentLoading to invoke_Agent_OnAttach

Except for the possible addition of some comments regarding what is meant by "loaded", the changes look good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14244#pullrequestreview-1455750113

From alanb at openjdk.org  Thu Jun  1 15:31:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Jun 2023 15:31:04 GMT
Subject: RFR: 8309146: extend JDI StackFrame.setValue() and JDWP
 StackFrame.setValues minimal support for virtual threads
In-Reply-To: <PTH8uTnjL0i6z3fUXEXGZpVlg-IvkaU-AQFsgZJeG0k=.65f1958f-9fe4-4b46-a214-cb79e1b04575@github.com>
References: <PTH8uTnjL0i6z3fUXEXGZpVlg-IvkaU-AQFsgZJeG0k=.65f1958f-9fe4-4b46-a214-cb79e1b04575@github.com>
Message-ID: <FvRwZqNQqfscc7ENwx07hL9hSb47p9uafOAuBSbUroQ=.ce2ff8b1-97f8-4b71-aa02-9933f063c1f8@github.com>

On Tue, 30 May 2023 23:44:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The JDWP spec for StackFrame.SetValue currently states:
> 
>         "If the thread is a virtual thread then this command can be used to set "
>         "the value of local variables in the top-most frame when the thread is "
>         "suspended at a breakpoint or single step event. The target VM may support "
>         "setting local variables in other cases."
> 
> The JDI spec for StackFrame.setValue() has similar wording. In [JDK-8308814](https://bugs.openjdk.org/browse/JDK-8308814) the JVMTI spec clarified support to be for a thread suspended at any event, not just a breakpoint or single step. That same clarification is needed in the JDWP and JDI specs. No implementation changes are needed.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14235#pullrequestreview-1455759449

From cjplummer at openjdk.org  Thu Jun  1 15:32:16 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 1 Jun 2023 15:32:16 GMT
Subject: RFR: 8308232: nsk/jdb tests don't pass -verbose flag to the
 debuggee
In-Reply-To: <BCtPMH4tBXv4J_qKz_MiMSTiX35QxzatEBrz4XolkHk=.7bd23df5-1bdd-4569-a024-150c4139e10d@github.com>
References: <BCtPMH4tBXv4J_qKz_MiMSTiX35QxzatEBrz4XolkHk=.7bd23df5-1bdd-4569-a024-150c4139e10d@github.com>
Message-ID: <Uelr-CuXPSWteq0Nt6xv6mYrjcupud586qNvfuocCv8=.2024a990-a4ce-44ba-8196-e8e1a867a262@github.com>

On Wed, 31 May 2023 00:27:16 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The nsk/jdb tests are not passing the test args on to the debuggee. I found a way to pass all of them (see the CR for details), but Windows had trouble with the parsing. It turns out the only args that the debuggee really cares about are -verbose and -waittime, so I settled on just passing these two, and Windows is happy.
> 
> Note only a handful of tests run with -verbose as the default. However, with this change at least now if you add -verbose when debugging an issue, you will see verbose log output from the debuggee. Previously you would not.

Thanks for the reviews Serguei and Leonid!

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

PR Comment: https://git.openjdk.org/jdk/pull/14236#issuecomment-1572270309

From cjplummer at openjdk.org  Thu Jun  1 15:32:16 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 1 Jun 2023 15:32:16 GMT
Subject: Integrated: 8308232: nsk/jdb tests don't pass -verbose flag to the
 debuggee
In-Reply-To: <BCtPMH4tBXv4J_qKz_MiMSTiX35QxzatEBrz4XolkHk=.7bd23df5-1bdd-4569-a024-150c4139e10d@github.com>
References: <BCtPMH4tBXv4J_qKz_MiMSTiX35QxzatEBrz4XolkHk=.7bd23df5-1bdd-4569-a024-150c4139e10d@github.com>
Message-ID: <oB-HNSErvYSfFJ-qoGBwscLiugoR8UXL1lFE7ntvlXA=.f4f7fee4-bf03-43ac-8eb0-dbafc9b0c255@github.com>

On Wed, 31 May 2023 00:27:16 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The nsk/jdb tests are not passing the test args on to the debuggee. I found a way to pass all of them (see the CR for details), but Windows had trouble with the parsing. It turns out the only args that the debuggee really cares about are -verbose and -waittime, so I settled on just passing these two, and Windows is happy.
> 
> Note only a handful of tests run with -verbose as the default. However, with this change at least now if you add -verbose when debugging an issue, you will see verbose log output from the debuggee. Previously you would not.

This pull request has now been integrated.

Changeset: c6f20db9
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c6f20db945c6217aea84cebd6c97dbf8b93c48a4
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8308232: nsk/jdb tests don't pass -verbose flag to the debuggee

Reviewed-by: sspitsyn, lmesnik

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

PR: https://git.openjdk.org/jdk/pull/14236

From cjplummer at openjdk.org  Thu Jun  1 15:36:18 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 1 Jun 2023 15:36:18 GMT
Subject: RFR: 8309146: extend JDI StackFrame.setValue() and JDWP
 StackFrame.setValues minimal support for virtual threads
In-Reply-To: <PTH8uTnjL0i6z3fUXEXGZpVlg-IvkaU-AQFsgZJeG0k=.65f1958f-9fe4-4b46-a214-cb79e1b04575@github.com>
References: <PTH8uTnjL0i6z3fUXEXGZpVlg-IvkaU-AQFsgZJeG0k=.65f1958f-9fe4-4b46-a214-cb79e1b04575@github.com>
Message-ID: <YH3JGkagzh75shLlF7MSx-8V3CvIUXocPy2Qv7o8qXA=.d51942b4-9095-4718-a532-c066fda51ac6@github.com>

On Tue, 30 May 2023 23:44:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The JDWP spec for StackFrame.SetValue currently states:
> 
>         "If the thread is a virtual thread then this command can be used to set "
>         "the value of local variables in the top-most frame when the thread is "
>         "suspended at a breakpoint or single step event. The target VM may support "
>         "setting local variables in other cases."
> 
> The JDI spec for StackFrame.setValue() has similar wording. In [JDK-8308814](https://bugs.openjdk.org/browse/JDK-8308814) the JVMTI spec clarified support to be for a thread suspended at any event, not just a breakpoint or single step. That same clarification is needed in the JDWP and JDI specs. No implementation changes are needed.

Thanks for the reviews Serguei and Alan!

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

PR Comment: https://git.openjdk.org/jdk/pull/14235#issuecomment-1572279020

From cjplummer at openjdk.org  Thu Jun  1 15:36:18 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 1 Jun 2023 15:36:18 GMT
Subject: Integrated: 8309146: extend JDI StackFrame.setValue() and JDWP
 StackFrame.setValues minimal support for virtual threads
In-Reply-To: <PTH8uTnjL0i6z3fUXEXGZpVlg-IvkaU-AQFsgZJeG0k=.65f1958f-9fe4-4b46-a214-cb79e1b04575@github.com>
References: <PTH8uTnjL0i6z3fUXEXGZpVlg-IvkaU-AQFsgZJeG0k=.65f1958f-9fe4-4b46-a214-cb79e1b04575@github.com>
Message-ID: <gtXedJIy5ql6pCn7IL5oOSE2gHR7t31B90DnCAjCRqs=.630df778-46e0-4921-8630-f95ee1d4197d@github.com>

On Tue, 30 May 2023 23:44:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The JDWP spec for StackFrame.SetValue currently states:
> 
>         "If the thread is a virtual thread then this command can be used to set "
>         "the value of local variables in the top-most frame when the thread is "
>         "suspended at a breakpoint or single step event. The target VM may support "
>         "setting local variables in other cases."
> 
> The JDI spec for StackFrame.setValue() has similar wording. In [JDK-8308814](https://bugs.openjdk.org/browse/JDK-8308814) the JVMTI spec clarified support to be for a thread suspended at any event, not just a breakpoint or single step. That same clarification is needed in the JDWP and JDI specs. No implementation changes are needed.

This pull request has now been integrated.

Changeset: e8271649
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e8271649e00771a8bbee240aa1bbbc27a672b22a
Stats:     5 lines in 2 files changed: 0 ins; 0 del; 5 mod

8309146: extend JDI StackFrame.setValue() and JDWP StackFrame.setValues minimal support for virtual threads

Reviewed-by: sspitsyn, alanb

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

PR: https://git.openjdk.org/jdk/pull/14235

From daniel.daugherty at oracle.com  Thu Jun  1 15:49:37 2023
From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com)
Date: Thu, 1 Jun 2023 11:49:37 -0400
Subject: Clarifying jmethodID Usage and Potential JVM Crashes
In-Reply-To: <e44d0811-76ca-aabe-c7df-08062e77d011@oracle.com>
References: <CAPb8aJ5K_1yk0FwTZOt_vzTXppB_=w5zK3guT6MDu6mpxeVRQA@mail.gmail.com>
 <31e606ae-f54e-c8e6-c00b-720ef192d279@oracle.com>
 <CAPb8aJ5kwQBLusLw0BWQQ9MGinmfu-HRfoo1cfBAEcP9AoC=7Q@mail.gmail.com>
 <e44d0811-76ca-aabe-c7df-08062e77d011@oracle.com>
Message-ID: <154b6144-c209-af23-cc63-91b40f51076f@oracle.com>

Hmmm... seems like concurrent class unloading has revealed a situation 
in some
code where class refs should have been held, but were not held because 
it's very
difficult to do, and the code (mostly) got away with it for a long time...

David's quote from the JNI spec makes things very, very clear:

 > "A field or method ID does not prevent the VM from unloading the 
class from
 > which the ID has been derived. After the class is unloaded, the method or
 > field ID becomes invalid and may not be passed to any function taking 
such
 > an ID. The native code, therefore, must make sure to:
 >?? - keep a live reference to the underlying class, or
 >?? - recompute the method or field ID
 >
 > if it intends to use a method or field ID for an extended period of 
time."

and the JVM/TI spec does depend on the JNI spec for certain pieces like the
semantics of jmethodID.

I agree with David that fixing this is going to be difficult and a major
effort which is why we've all only chipped at this boulder before...

Dan


On 6/1/23 4:28 AM, David Holmes wrote:
> On 1/06/2023 5:16 pm, Jaroslav Bachor?k wrote:
>> Hi David,
>>
>> On Thu, Jun 1, 2023 at 3:56?AM David Holmes <david.holmes at oracle.com 
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>> ??? Hi Jaroslav,
>>
>> ??? On 31/05/2023 9:12 pm, Jaroslav Bachor?k wrote:
>> ???? > Dear Team,
>> ???? >
>> ???? > I've been investigating the unusual JVM crashes occurring in
>> ??? JVMTI calls
>> ???? > on a J9 JVM. During my investigation, I scrutinized the 
>> `jmethodID`
>> ???? > definition closely, available here: [jmethodID
>> ???? >
>> definition](https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#jmethodID 
>> <https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#jmethodID> 
>> <https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#jmethodID 
>> <https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#jmethodID>>). 
>>
>> ???? >
>> ???? > To paraphrase, the definition suggests that `jmethodID` 
>> identifies a
>> ???? > Java method, initializer, or constructor. These identifiers, once
>> ???? > returned by JVM TI functions and events, can be safely stored.
>> ??? However,
>> ???? > when the class is unloaded, they become invalid, rendering them
>> ???? > unsuitable for use.
>> ???? >
>> ???? > My interpretation is that the JVMTI user should verify the
>> ??? validity of a
>> ???? > `jmethodID` value before using it to prevent potential crashes.
>> ??? Would
>> ???? > you agree with this interpretation?
>>
>> ??? Not quite - as you note you can't verify the jmethodID validity. 
>> What
>> ??? the user needs to do, in line with what Dan was saying, is ensure 
>> that
>> ??? they keep track of the classes to which the methods belong and keep
>> ??? them
>> ??? alive if necessary. Now that may be easier said than done, but 
>> that is
>> ??? the gist of it. This comes from the JNI spec:
>>
>> ??? "A field or method ID does not prevent the VM from unloading the 
>> class
>> ??? from which the ID has been derived. After the class is unloaded, the
>> ??? method or field ID becomes invalid and may not be passed to any
>> ??? function
>> ??? taking such an ID. The native code, therefore, must make sure to:
>>
>> ???? ? ? ?keep a live reference to the underlying class, or
>> ???? ? ? ?recompute the method or field ID
>>
>> ??? if it intends to use a method or field ID for an extended period of
>> ??? time."
>>
>> ???? > This sounds like a sensible requirement, but its practical
>> ??? application
>> ???? > remains unclear. As far as I know, methods can be unloaded
>> ??? concurrently
>> ???? > to the native code executing JVMTI functions. This introduces a
>> ???? > potential race condition where the JVM unloads the methods during
>> ??? the
>> ???? > check->use flow, making it only a partial solution. To complicate
>> ???? > matters further, no method exists to confirm whether a
>> ??? `jmethodID` is valid.
>> ???? >
>> ???? > Theoretically, we could monitor the `CompiledMethodUnload` 
>> event to
>> ???? > track the validity state, creating a constantly expanding set of
>> ???? > unloaded `jmethodID` values or a bloom filter, if one does not 
>> care
>> ???? > about few potential false positives. This strategy, however, 
>> doesn't
>> ???? > address the potential race condition, and it could even
>> ??? exacerbate it
>> ???? > due to possible event delays. This delay might mistakenly 
>> validate a
>> ???? > `jmethodID` value that has already been unloaded, but for 
>> which the
>> ???? > event hasn't been delivered yet.
>> ???? >
>> ???? > Honestly, I don't see a way to use `jmethodID` safely unless the
>> ??? code
>> ???? > using it suspends the entire JVM and doesn't resume until it's
>> ??? finished
>> ???? > with that `jmethodID`. Any other approach might lead to JVM
>> ??? crashes, as
>> ???? > we've observed with J9.
>> ???? >
>> ???? > Lastly, it's noteworthy that Hotspot takes meticulous measures to
>> ??? ensure
>> ???? > that using jmethodIDs for unloaded methods doesn't crash the 
>> JVM and
>> ???? > even provides useful information. This observation has led me to
>> ???? > question whether the documentation aligns with the Hotspot
>> ???? > implementation, especially given that following closely the
>> ???? > documentation appears to increase the risk associated with the
>> ??? use of
>> ???? > `jmethodID` values.
>>
>> ??? There have been folk who wanted to make this area more user-friendly
>> ??? but
>> ??? that shouldn't be mistaken for moving towards a world where 
>> jmethodIDs
>> ??? are always safe to use.
>>
>>
>> Yes, I see your point. Unfortunately, this confirms my worries that 
>> using AsyncGetCallTrace (ASGCT) on a system strictly adhering to the 
>> JVMTI spec of jmethoID is not really possible without risking random 
>> and quite frequent crashes on systems with concurrent class unloading 
>> enabled.
>> FTR, ASGCT will record the stack trace as a list of frames, each one 
>> containing?the corresponding jmethodID value. Considering that the 
>> most common usage of ASGCT is in a signal handler it makes it 
>> impossible to use JVMTI calls to resolve the holder class and create 
>> a strong reference to prevent it from being unloaded.
>> And even if this would be possible we would need to figure out when 
>> to release the class reference when it is no more needed - and it is 
>> not really clear how we could do that reliably, leaving us with the 
>> option of holding the class references indefinitely or risking 
>> crashing JVM.
>
> I would have to agree you cannot use jmethodID's for that purpose, not 
> without also recording (and keeping-alive) the associated classes. As 
> to when you would clear such references I can't say as I don't know 
> how the ASGCT stack record would be used.
>
>> I want to emphasize that not being able to resolve additional details 
>> for a jmethodID pointing to a method of an unloaded class is not an 
>> issue, as long as the JVMTI call does not crash. I think that 
>> https://bugs.openjdk.org/browse/JDK-8268364 
>> <https://bugs.openjdk.org/browse/JDK-8268364> did address exactly the 
>> problem of concurrent class unloading causing races in the code that 
>> is checking for validity of jmethodID and then using it.
>
> Yes but internal to the JVMTI implementation. The basic null check 
> that was used was found to be insufficient when used with ZGC and so 
> we would crash more often than was considered reasonable. There is a 
> quoted comment in the code in 
> https://bugs.openjdk.org/browse/JDK-8268088:
>
> ? // These aren't deallocated and are going to look like a leak, but 
> that's
> ? // needed because we can't really get rid of jmethodIDs because we 
> don't
> ? // know when native code is going to stop using them. The spec says 
> that
> ? // they're "invalid" but existing programs likely rely on their being
> ? // NULL after class unloading.
>
> that kind of sums up the position of trying to accommodate "bad code" 
> in a reasonable way.
>
>> Can this be summarize in a way that the user is not guaranteed to get 
>> any additional information for an invalid jmethodID but it would be 
>> really nice for JVM not to crash when jmethodID becomes invalid as 
>> there is no way for the user to check for its validity in an atomic 
>> manner
>> - and yes, even calling GetMethodDeclaringClass in order to obtain 
>> the class one could create a strong reference is a subject to racy 
>> behaviour so it really can not be used as a workaround.
>
> The only real solution IMO would be to encode jmethodIDs in a way that 
> validity can be tracked and then have all JVMTI methods be able to 
> check that validity and guarantee atomicity of the method such that 
> the id can't become invalid whilst in use. Whether that is at all 
> feasible/practical I do not know - but it sounds like a major effort 
> to me.
>
> Cheers,
> David
>
>> Cheers,
>>
>> -JB-
>>
>>
>> ??? Cheers,
>> ??? David
>>
>> ???? > I welcome your thoughts and perspectives on this matter.
>> ???? >
>> ???? > Best regards,
>> ???? >
>> ???? > Jaroslav
>>


From cjplummer at openjdk.org  Thu Jun  1 15:59:10 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 1 Jun 2023 15:59:10 GMT
Subject: RFR: 8304438: jcmd JVMTI.agent_load should obey
 EnableDynamicAgentLoading [v3]
In-Reply-To: <SuKybfixTCm3WLfYJC99C226u_LIeXHFBmRE1Xcne_k=.2ec883df-c5de-47fa-b27e-79955e16978f@github.com>
References: <9H36lIpFiwG4v0oGPE2zCIawMJcNIhuGguz--qxjRnQ=.0fc08ed3-2d12-42d0-8b6c-3fa801d55427@github.com>
 <SuKybfixTCm3WLfYJC99C226u_LIeXHFBmRE1Xcne_k=.2ec883df-c5de-47fa-b27e-79955e16978f@github.com>
Message-ID: <oKSWujO4EiiGSuJYXqFiSjXAnNcR8OSxHPfxH1c6Ovw=.c959f53c-67d8-4750-8af7-93ffcb3dfc6a@github.com>

On Wed, 31 May 2023 23:39:19 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The VM option EnableDynamicAgentLoading was added in JDK 9, default true, to allow deployment to choose whether to allow agents to be loaded/started in the VM. The VM option does the right thing for tools using the Attach API but jcmd JVMTI.agent_load was missed. This should be fixed to disallow loading JVMTI agents when the EnableDynamicAgentLoading is false.
>> 
>> The CSR is:
>> [JDK-8309250](https://bugs.openjdk.org/browse/JDK-8309250): jcmd JVMTI.agent_load should obey EnableDynamicAgentLoading
>> 
>> Testing:
>>  - run new test `test/jdk/sun/tools/jcmd/TestJcmdNoAgentLoad.java`
>>  - TBD: submit mach5 tiers 1-5 to make sure no new regressions are introduced
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move check for EnableDynamicAgentLoading to invoke_Agent_OnAttach

Sorry, previous comment was for another review.

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

Changes requested by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14244#pullrequestreview-1455813557

From cjplummer at openjdk.org  Thu Jun  1 16:00:12 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 1 Jun 2023 16:00:12 GMT
Subject: RFR: 8307478: Implementation of Prepare to Restrict The Dynamic
 Loading of Agents [v8]
In-Reply-To: <p9MSGJXheJQU5ZaZqzVfu_MN-J5fKbuTrP0SyUQuCkc=.9af25da9-0c08-4866-bde1-1831b23d8e63@github.com>
References: <MA536Tpr3slk80MYAPS3P9fAsy-QLDNZpvN2pNvUGLA=.e2960455-4580-46f7-992d-39f625dac8cc@github.com>
 <p9MSGJXheJQU5ZaZqzVfu_MN-J5fKbuTrP0SyUQuCkc=.9af25da9-0c08-4866-bde1-1831b23d8e63@github.com>
Message-ID: <CSAfJT6Q5AXCW_3uE2zGCjB3qZUv9TW8Usacx-DWoTI=.e17d1dd1-a0de-4cef-b39d-00ddbd75f93b@github.com>

On Thu, 1 Jun 2023 12:37:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation for JEP 451. There are two parts to this:
>> 
>> 1. A multi-line warning is printed when a JVM TI or Java agent is loaded into a running VM. For JVM TI, the message is printed to stderr from JvmtiAgent::load. For Java agents, it is printed to System.err (as that may be redirected) in the JPLIS (j.l.instrumentation) implementation. This part includes an update to the JVM TI spec and API docs to require the warning.
>> 
>> 2. If running with -Djdk.instrument.traceUsage or -Djdk.instrument.traceUsage=true, the calls to the Instrumentation API print a trace message and stack trace.
>> 
>> Testing: tier1-6
>
> Alan Bateman 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 19 additional commits since the last revision:
> 
>  - Split is_loaded, typos in comments
>  - Merge
>  - Add impl note to document the XX option
>  - Cleanup
>  - Merge
>  - Allow for warning to be skipped when same agent loaded a second/subsequent time
>  - Merge
>  - Tweak javadoc, update test to use more test infra
>  - Merge
>  - Merge
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/25f0fc82...cbd9bb1d

Except for the possible addition of some comments regarding what is meant by "loaded", the changes look good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13899#pullrequestreview-1455815464

From alanb at openjdk.org  Thu Jun  1 16:56:17 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Jun 2023 16:56:17 GMT
Subject: RFR: 8307478: Implementation of Prepare to Restrict The Dynamic
 Loading of Agents [v9]
In-Reply-To: <MA536Tpr3slk80MYAPS3P9fAsy-QLDNZpvN2pNvUGLA=.e2960455-4580-46f7-992d-39f625dac8cc@github.com>
References: <MA536Tpr3slk80MYAPS3P9fAsy-QLDNZpvN2pNvUGLA=.e2960455-4580-46f7-992d-39f625dac8cc@github.com>
Message-ID: <9REwwZtBlDauy0udqsxSLqEXpXkt5Jp3Wv-BOnYTGu0=.c10bfd0a-5b8a-45a6-9570-1b4d939a2c33@github.com>

> This is the implementation for JEP 451. There are two parts to this:
> 
> 1. A multi-line warning is printed when a JVM TI or Java agent is loaded into a running VM. For JVM TI, the message is printed to stderr from JvmtiAgent::load. For Java agents, it is printed to System.err (as that may be redirected) in the JPLIS (j.l.instrumentation) implementation. This part includes an update to the JVM TI spec and API docs to require the warning.
> 
> 2. If running with -Djdk.instrument.traceUsage or -Djdk.instrument.traceUsage=true, the calls to the Instrumentation API print a trace message and stack trace.
> 
> Testing: tier1-6

Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:

  Add comment to invoke_Agent_OnAttach

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13899/files
  - new: https://git.openjdk.org/jdk/pull/13899/files/cbd9bb1d..71f9886a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13899&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13899&range=07-08

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13899.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13899/head:pull/13899

PR: https://git.openjdk.org/jdk/pull/13899

From ysr at openjdk.org  Thu Jun  1 17:55:20 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 1 Jun 2023 17:55:20 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental)
In-Reply-To: <jpxh4BWV3qIL825gPzqs5atQcW15MdbpRS1jluaC51A=.080c2545-2e01-4f22-8cd3-f607d19188de@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <jpxh4BWV3qIL825gPzqs5atQcW15MdbpRS1jluaC51A=.080c2545-2e01-4f22-8cd3-f607d19188de@github.com>
Message-ID: <HIrdbGBI8m3bxLaRXxZt34nqUHGPkS0gRbe9Wh1ohjU=.ed3ca34c-2d84-4802-a18d-bea482972f9e@github.com>

On Thu, 1 Jun 2023 12:15:37 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Issues already reported to GenShen engineers:
> 
> gc/shenandoah/TestElasticTLAB.java#generational #? Internal Error (src\hotspot\share\gc\shenandoah\shenandoahFreeSet.cpp:695), pid=23288, tid=23784 #? assert(size % CardTable::card_size_in_words() == 0) failed: size must be multiple of card table size, was 258
> 
> gc/stress/gcold/TestGCOldWithShenandoah.java#generational #? Internal Error (src\hotspot\share\gc\shenandoah\heuristics\shenandoahOldHeuristics.cpp:82), pid=20828, tid=5836 #? assert(_old_generation->available() > old_evacuation_budget) failed: Cannot budget more than is available
> 
> gc/shenandoah/oom/TestAllocOutOfMemory.java#large Execution failed: `main' threw exception: java.lang.RuntimeException: 'java.lang.OutOfMemoryError: Java heap space' missing from stdout/stderr (Issue with 64k Pages)
> 
> gc/shenandoah/TestRetainObjects.java#no-tlab gc/shenandoah/TestSieveObjects.java#no-tlab Timeouts.
> 
> gc/shenandoah/TestAllocObjects.java#generational gc/shenandoah/TestDynamicSoftMaxHeapSize.java#generational #? Internal Error src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp:664), pid=18434, tid=29955 #? assert(is_global() || ShenandoahHeap::heap()->is_full_gc_in_progress() || (_used + _humongous_waste <= _affiliated_region_count * ShenandoahHeapRegion::region_size_bytes())) failed: used cannot exceed regions

Thanks @TheRealMDoerr ; could you specify the platforms on which you see these failures, so we have a better chance at reproducing them? Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/14185#issuecomment-1572528277

From kdnilsen at openjdk.org  Thu Jun  1 18:07:53 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 1 Jun 2023 18:07:53 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v2]
In-Reply-To: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
Message-ID: <ux7j8nPOoAZnNmZWfQPKwuMYM0I31n3EthJ3yToqUeQ=.792e8c53-5fb4-453e-a4dd-177f194a9945@github.com>

> 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:

  Make the order of young/old collector checks consistent (#1)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14185/files
  - new: https://git.openjdk.org/jdk/pull/14185/files/aa85a907..eb656ec2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14185&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14185&range=00-01

  Stats: 16 lines in 1 file changed: 7 ins; 8 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

From wkemper at openjdk.org  Thu Jun  1 18:42:25 2023
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 1 Jun 2023 18:42:25 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v2]
In-Reply-To: <xm0flhnqe2E9BneRAuuKvqdFCE-JMGIbKKJ9rL1xo7o=.3fc52141-a58e-4bad-9d33-e4c521896613@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <xm0flhnqe2E9BneRAuuKvqdFCE-JMGIbKKJ9rL1xo7o=.3fc52141-a58e-4bad-9d33-e4c521896613@github.com>
Message-ID: <b8RigFpA-HSd8HsCbeo5izojOGn-9KPvoK_4XuW0WZU=.fb64e25f-5215-4fbb-a416-1f579075062a@github.com>

On Thu, 1 Jun 2023 10:12:02 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make the order of young/old collector checks consistent (#1)
>
> src/hotspot/share/gc/shared/gcConfiguration.cpp line 88:
> 
>> 86:     }
>> 87: #endif
>> 88:     return NA;
> 
> You moved the order between Shenandoah and ZGC in `young_collector()`, so you should probably do the same here.

Fixed. Thank you for the review.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1213538282

From cjplummer at openjdk.org  Thu Jun  1 19:41:13 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 1 Jun 2023 19:41:13 GMT
Subject: RFR: 8307478: Implementation of Prepare to Restrict The Dynamic
 Loading of Agents [v9]
In-Reply-To: <9REwwZtBlDauy0udqsxSLqEXpXkt5Jp3Wv-BOnYTGu0=.c10bfd0a-5b8a-45a6-9570-1b4d939a2c33@github.com>
References: <MA536Tpr3slk80MYAPS3P9fAsy-QLDNZpvN2pNvUGLA=.e2960455-4580-46f7-992d-39f625dac8cc@github.com>
 <9REwwZtBlDauy0udqsxSLqEXpXkt5Jp3Wv-BOnYTGu0=.c10bfd0a-5b8a-45a6-9570-1b4d939a2c33@github.com>
Message-ID: <3ieyvgzfEF6sPJy4o-mxJx4NdL9T1i3115ktZMZ0oKA=.f1324163-b27c-4938-b5e6-8423e27ccad7@github.com>

On Thu, 1 Jun 2023 16:56:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation for JEP 451. There are two parts to this:
>> 
>> 1. A multi-line warning is printed when a JVM TI or Java agent is loaded into a running VM. For JVM TI, the message is printed to stderr from JvmtiAgent::load. For Java agents, it is printed to System.err (as that may be redirected) in the JPLIS (j.l.instrumentation) implementation. This part includes an update to the JVM TI spec and API docs to require the warning.
>> 
>> 2. If running with -Djdk.instrument.traceUsage or -Djdk.instrument.traceUsage=true, the calls to the Instrumentation API print a trace message and stack trace.
>> 
>> Testing: tier1-6
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment to invoke_Agent_OnAttach

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13899#pullrequestreview-1456185001

From mseledtsov at openjdk.org  Thu Jun  1 22:01:08 2023
From: mseledtsov at openjdk.org (Mikhailo Seledtsov)
Date: Thu, 1 Jun 2023 22:01:08 GMT
Subject: RFR: 8308090: Add container tests for on-the-fly resource quota
 updates [v2]
In-Reply-To: <wM_d0lw-QV0H7VsCiI0QdOM-PKynxEFgz6wOVSPoJAU=.72b784bf-3656-4551-a3c9-1c33eb748e28@github.com>
References: <w8L1msIb1ImXE3bWx4ZLaX3mg4MH_shRsN3CObIb-Ew=.1841e10b-595a-4bbb-9368-68897e4306df@github.com>
 <wM_d0lw-QV0H7VsCiI0QdOM-PKynxEFgz6wOVSPoJAU=.72b784bf-3656-4551-a3c9-1c33eb748e28@github.com>
Message-ID: <vSn81I9V8XI0k8n5SaD95JelG0xFF-kOzSz4N05jH1w=.7bbf1edc-ffcf-4ca5-a810-6b83b93ec69d@github.com>

On Tue, 23 May 2023 09:04:11 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review these test changes which implement automatic testing of container resource updates without JVM restart. Note that this merely tests container detection code handling this case. It doesn't do anything special for the JVM itself, though it might make sense to add some sanity checks should we detect certain limits changing. In another PR, though.
>> 
>> As to the test design, it works similar to the shared temp tests: Interact between the two containers by virtue of a shared filesystem `/tmp` and creating marker files there in order to make them cooperate. Note that the new test needs `podman` version `4.3.0` and better (`4.5` is current).
>> 
>> Testing:
>>  - [x] GHA
>>  - [x] Linux x86_64 container tests on cg v1 and cg v2 system
>>  - [x] Newly added tests on Linux x86_64 cg v1 and cg v2 (`podman` and `docker`)
>
> Severin Gehwolf 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-8308090-tests-container-on-fly-updates
>  - Fix whitespace
>  - 8308090: Add container tests for on-the-fly resource quota updates

Changes look good to me. Thank you for adding these tests.

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

Marked as reviewed by mseledtsov (Committer).

PR Review: https://git.openjdk.org/jdk/pull/14090#pullrequestreview-1456374316

From sspitsyn at openjdk.org  Thu Jun  1 22:51:23 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 1 Jun 2023 22:51:23 GMT
Subject: RFR: 8304438: jcmd JVMTI.agent_load should obey
 EnableDynamicAgentLoading [v4]
In-Reply-To: <9H36lIpFiwG4v0oGPE2zCIawMJcNIhuGguz--qxjRnQ=.0fc08ed3-2d12-42d0-8b6c-3fa801d55427@github.com>
References: <9H36lIpFiwG4v0oGPE2zCIawMJcNIhuGguz--qxjRnQ=.0fc08ed3-2d12-42d0-8b6c-3fa801d55427@github.com>
Message-ID: <9DAQ0XpB6JlntsaEu1TZNirVwkT7kewRhKdfeIgoN4s=.d8741a54-876e-4691-9471-a77d392f9ff9@github.com>

> The VM option EnableDynamicAgentLoading was added in JDK 9, default true, to allow deployment to choose whether to allow agents to be loaded/started in the VM. The VM option does the right thing for tools using the Attach API but jcmd JVMTI.agent_load was missed. This should be fixed to disallow loading JVMTI agents when the EnableDynamicAgentLoading is false.
> 
> The CSR is:
> [JDK-8309250](https://bugs.openjdk.org/browse/JDK-8309250): jcmd JVMTI.agent_load should obey EnableDynamicAgentLoading
> 
> Testing:
>  - run new test `test/jdk/sun/tools/jcmd/TestJcmdNoAgentLoad.java`
>  - TBD: submit mach5 tiers 1-5 to make sure no new regressions are introduced

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: use output.shouldContain()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14244/files
  - new: https://git.openjdk.org/jdk/pull/14244/files/be0ec0c9..062b3f85

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14244&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14244&range=02-03

  Stats: 15 lines in 1 file changed: 0 ins; 14 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14244.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14244/head:pull/14244

PR: https://git.openjdk.org/jdk/pull/14244

From sspitsyn at openjdk.org  Thu Jun  1 22:51:25 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 1 Jun 2023 22:51:25 GMT
Subject: RFR: 8304438: jcmd JVMTI.agent_load should obey
 EnableDynamicAgentLoading [v2]
In-Reply-To: <TywHHGqhaYYEOLCJab4FFATxcxzDFvWr3Bm_GwZarvk=.c9f4360c-43ad-4d9b-909b-f47a36c52a97@github.com>
References: <9H36lIpFiwG4v0oGPE2zCIawMJcNIhuGguz--qxjRnQ=.0fc08ed3-2d12-42d0-8b6c-3fa801d55427@github.com>
 <uXvLeD6gVSY1R0nsd2xv2KUhp-hsC8quaPALOFuk_cY=.b35ec2be-edb1-4b2d-bf0f-56aa42f97081@github.com>
 <TywHHGqhaYYEOLCJab4FFATxcxzDFvWr3Bm_GwZarvk=.c9f4360c-43ad-4d9b-909b-f47a36c52a97@github.com>
Message-ID: <R-_rNZXqQNiIehrjOxmnv6Ti_jrTJFqMn2-d1i-wFIg=.27c6d01b-715e-4276-afc7-f11443e25a45@github.com>

On Wed, 31 May 2023 22:08:43 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor renaming in new test TestJcmdNoAgentLoad.java
>
> test/jdk/sun/tools/jcmd/TestJcmdNoAgentLoad.java line 68:
> 
>> 66:                 System.out.println("Found output line with the expected error message:\n" + line);
>> 67:             }
>> 68:         }
> 
> Why not just use  `OutputAnalyzer.shouldContain()`?

Good suggestion, thanks. I've not found this method. :)

> test/jdk/sun/tools/jcmd/TestJcmdNoAgentLoad.java line 70:
> 
>> 68:         }
>> 69:         if (!seenPattern) {
>> 70:             throw new RuntimeException("Not found expected error message in output");
> 
> "Not found" -> "Did not find"
> 
> Also, you should include the expected error message in the output.

Okay. But I've replaced this code with `OutputAnalyzer.shouldContain()` as you suggested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14244#discussion_r1213750622
PR Review Comment: https://git.openjdk.org/jdk/pull/14244#discussion_r1213751619

From cjplummer at openjdk.org  Thu Jun  1 23:11:23 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 1 Jun 2023 23:11:23 GMT
Subject: RFR: 8309329: com/sun/jdi/DeferredStepTest.java fails with virtual
 threads due to not waiting for threads to exit
Message-ID: <9WLOY1a8lk3w-ZTrN-SUCOQXdwHideyuexQNjKXPJ9M=.2f555619-bcb4-4f30-8d17-97b0147c58e1@github.com>

Virtual threads are always daemon threads, so tests that previously did not explicitly wait for test threads to exit sometimes fail with virtual threads due to the test exiting before the test threads have exited. A join() for each test thread is needed to fix this issue.

com/sun/jdi/DeferredStepTest.java is one such tests. I looked at the other com/sun/jdi failures listed in [JDK-8285422](https://bugs.openjdk.org/browse/JDK-8285422) and didn't see any others that might be failing for this same reason.

I tested locally with `JTREG_TEST_THREAD_FACTORY=Virtual`. I'll also run the appropriate mach5 tier that tests com/sun/jdi with virtual threads.

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

Commit messages:
 - Use join() to make sure test threads have exited

Changes: https://git.openjdk.org/jdk/pull/14275/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14275&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309329
  Stats: 12 lines in 2 files changed: 9 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14275.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14275/head:pull/14275

PR: https://git.openjdk.org/jdk/pull/14275

From cjplummer at openjdk.org  Thu Jun  1 23:17:07 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 1 Jun 2023 23:17:07 GMT
Subject: RFR: 8304438: jcmd JVMTI.agent_load should obey
 EnableDynamicAgentLoading [v4]
In-Reply-To: <9DAQ0XpB6JlntsaEu1TZNirVwkT7kewRhKdfeIgoN4s=.d8741a54-876e-4691-9471-a77d392f9ff9@github.com>
References: <9H36lIpFiwG4v0oGPE2zCIawMJcNIhuGguz--qxjRnQ=.0fc08ed3-2d12-42d0-8b6c-3fa801d55427@github.com>
 <9DAQ0XpB6JlntsaEu1TZNirVwkT7kewRhKdfeIgoN4s=.d8741a54-876e-4691-9471-a77d392f9ff9@github.com>
Message-ID: <p6YoUItcvlrz7h08aOZhtNllaFYvdGkSWqp2RZijE88=.a13aae0f-f5a1-4773-92cb-ffccab820d88@github.com>

On Thu, 1 Jun 2023 22:51:23 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The VM option EnableDynamicAgentLoading was added in JDK 9, default true, to allow deployment to choose whether to allow agents to be loaded/started in the VM. The VM option does the right thing for tools using the Attach API but jcmd JVMTI.agent_load was missed. This should be fixed to disallow loading JVMTI agents when the EnableDynamicAgentLoading is false.
>> 
>> The CSR is:
>> [JDK-8309250](https://bugs.openjdk.org/browse/JDK-8309250): jcmd JVMTI.agent_load should obey EnableDynamicAgentLoading
>> 
>> Testing:
>>  - run new test `test/jdk/sun/tools/jcmd/TestJcmdNoAgentLoad.java`
>>  - TBD: submit mach5 tiers 1-5 to make sure no new regressions are introduced
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: use output.shouldContain()

test/jdk/sun/tools/jcmd/TestJcmdNoAgentLoad.java line 57:

> 55:         OutputAnalyzer output = JcmdBase.jcmd(jcmdArgs);
> 56: 
> 57:         assertEquals(output.getExitValue(), 0);

I think tests normally just use `output.shouldHaveExitValue(0);`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14244#discussion_r1213766546

From amenkov at openjdk.org  Fri Jun  2 00:01:07 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 2 Jun 2023 00:01:07 GMT
Subject: RFR: 8308978: regression with a deadlock involving
 FollowReferences [v3]
In-Reply-To: <6xcKqU3mLr9TocEUpoXXzcNWSnKijSlhcyxIfXXrFD0=.2987b8de-827e-43d0-907b-7ef2016ddab4@github.com>
References: <2J1qItzUgmfjRPS0xUbHgXZQ-b12JBxe8XPRftU2GyA=.025e7855-5df4-413a-bea7-585a53832025@github.com>
 <6xcKqU3mLr9TocEUpoXXzcNWSnKijSlhcyxIfXXrFD0=.2987b8de-827e-43d0-907b-7ef2016ddab4@github.com>
Message-ID: <Liu6Ign1zpB2445NzDmZKREn1DXSSPBU0z7NfxIhr1Y=.00c89065-20d7-451e-b3b3-c03660aa47c2@github.com>

On Wed, 31 May 2023 21:33:13 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The change fixes regression from JDK-8299414.
>> There is a deadlock between JvmtiVTMSTransitionDisabler and EscapeBarrier when virtual threads are in mount/unmount transition:
>> EscapeBarrier requests deoptimization which requires thread suspension.
>> JvmtiVTMSTransitionDisabler ctor waits until all in progress VTMS transitions complete, but they cannot be completed as thread is suspended.
>> To avoid the deadlock mount/unmount transitions should be completed before EscapeBarrier stuff.
>
> Alex Menkov 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 eight additional commits since the last revision:
> 
>  - Merge branch 'follow_ref_deadlock' of github.com:alexmenkov/jdk into follow_ref_deadlock
>  - Merge branch 'openjdk:master' into follow_ref_deadlock
>  - Merge branch 'follow_ref_deadlock' of github.com:alexmenkov/jdk into follow_ref_deadlock
>  - fix
>  - unproblem-list tests
>  - fix
>  - unproblem-list tests
>  - fix

tier 1-5 passed (there are 3 failed tests, but they are not related to FollowReferences)

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

PR Comment: https://git.openjdk.org/jdk/pull/14233#issuecomment-1572934722

From amenkov at openjdk.org  Fri Jun  2 00:09:09 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 2 Jun 2023 00:09:09 GMT
Subject: RFR: 8309329: com/sun/jdi/DeferredStepTest.java fails with virtual
 threads due to not waiting for threads to exit
In-Reply-To: <9WLOY1a8lk3w-ZTrN-SUCOQXdwHideyuexQNjKXPJ9M=.2f555619-bcb4-4f30-8d17-97b0147c58e1@github.com>
References: <9WLOY1a8lk3w-ZTrN-SUCOQXdwHideyuexQNjKXPJ9M=.2f555619-bcb4-4f30-8d17-97b0147c58e1@github.com>
Message-ID: <H1MNJQQHQ1PqnkGNFqXiwu5TmpFWDADPo8n-OL_EzoU=.b0ae55f3-52dd-478c-96f1-b8fa9b311cbe@github.com>

On Thu, 1 Jun 2023 23:03:47 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Virtual threads are always daemon threads, so tests that previously did not explicitly wait for test threads to exit sometimes fail with virtual threads due to the test exiting before the test threads have exited. A join() for each test thread is needed to fix this issue.
> 
> com/sun/jdi/DeferredStepTest.java is one such tests. I looked at the other com/sun/jdi failures listed in [JDK-8285422](https://bugs.openjdk.org/browse/JDK-8285422) and didn't see any others that might be failing for this same reason.
> 
> I tested locally with `JTREG_TEST_THREAD_FACTORY=Virtual`. I'll also run the appropriate mach5 tier that tests com/sun/jdi with virtual threads.

test/jdk/com/sun/jdi/DeferredStepTest.java line 80:

> 78:         Thread jj2 = TestScaffold.newThread(obj2, "jj2");
> 79:         jj1.start();
> 80:         jj2.start();

It looks strange that there are no errors about conflict between variable names and class names.
Anyway I think it would be better to rename the variables

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14275#discussion_r1213789142

From kdnilsen at openjdk.org  Fri Jun  2 02:30:21 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 2 Jun 2023 02:30:21 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v3]
In-Reply-To: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
Message-ID: <AZxt9azWED3gmkS0F-myg_uTzNJ3cbNDVERW-Rb3RLs=.2e8bdc3b-5996-4874-9ec4-034c5e31ebdb@github.com>

> 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:

  Assert bounds only when allocations succeed, increase test timeouts (#2)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14185/files
  - new: https://git.openjdk.org/jdk/pull/14185/files/eb656ec2..5bf6e7e0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14185&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14185&range=01-02

  Stats: 3 lines in 3 files changed: 0 ins; 1 del; 2 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

From kdnilsen at openjdk.org  Fri Jun  2 02:49:25 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 2 Jun 2023 02:49:25 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v4]
In-Reply-To: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
Message-ID: <2sgbRGVCiStjmAspEqqpyWAM0IzbZfjFC6HHXlhbcyE=.9637c274-1b10-4103-b528-34719037362b@github.com>

> 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:

  Force PLAB sizes to align on card-table size

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14185/files
  - new: https://git.openjdk.org/jdk/pull/14185/files/5bf6e7e0..d4d2f1cf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14185&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14185&range=02-03

  Stats: 8 lines in 1 file changed: 8 ins; 0 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

From kdnilsen at openjdk.org  Fri Jun  2 02:56:23 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 2 Jun 2023 02:56:23 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v4]
In-Reply-To: <b8RigFpA-HSd8HsCbeo5izojOGn-9KPvoK_4XuW0WZU=.fb64e25f-5215-4fbb-a416-1f579075062a@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <xm0flhnqe2E9BneRAuuKvqdFCE-JMGIbKKJ9rL1xo7o=.3fc52141-a58e-4bad-9d33-e4c521896613@github.com>
 <b8RigFpA-HSd8HsCbeo5izojOGn-9KPvoK_4XuW0WZU=.fb64e25f-5215-4fbb-a416-1f579075062a@github.com>
Message-ID: <X9KxIxrGmRXoPOCGRv5AfCGjiZo0pUFiFQwBbn6Bs-Y=.b8f06043-ee20-4286-a1fb-efdd17dab64e@github.com>

On Thu, 1 Jun 2023 18:39:05 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/gcConfiguration.cpp line 88:
>> 
>>> 86:     }
>>> 87: #endif
>>> 88:     return NA;
>> 
>> You moved the order between Shenandoah and ZGC in `young_collector()`, so you should probably do the same here.
>
> Fixed. Thank you for the review.

Thanks.  We've made your suggested change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1213862862

From kdnilsen at openjdk.org  Fri Jun  2 02:56:25 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 2 Jun 2023 02:56:25 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v4]
In-Reply-To: <WuVIRjQQhANFoCsiipvCQd4wvKqSyMuYi5kuCA9dv70=.7f94f9a4-5653-4214-b411-9b32f58c7ed3@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <WuVIRjQQhANFoCsiipvCQd4wvKqSyMuYi5kuCA9dv70=.7f94f9a4-5653-4214-b411-9b32f58c7ed3@github.com>
Message-ID: <3lkkOfu3WxdRPQ4Y0uiOl6znrpRNDrcMn4ecDhQAcuU=.d742a62e-6ec7-444f-a925-f70dfeaf7df9@github.com>

On Thu, 1 Jun 2023 14:27:12 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Force PLAB sizes to align on card-table size
>
> test/hotspot/jtreg/gc/shenandoah/oom/TestClassLoaderLeak.java line 132:
> 
>> 130:              {{"iu"},           {"adaptive", "aggressive"}},
>> 131:              {{"passive"},      {"passive"}},
>> 132:              {{"generational"}, {"adaptive"}}
> 
> Curious, here and in similar places, why only test adaptive heuristic for generational, if we test satb with all variants?

Generational mode only works with adaptive heuristic.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1213863860

From sspitsyn at openjdk.org  Fri Jun  2 03:14:08 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 2 Jun 2023 03:14:08 GMT
Subject: RFR: 8304438: jcmd JVMTI.agent_load should obey
 EnableDynamicAgentLoading [v4]
In-Reply-To: <p6YoUItcvlrz7h08aOZhtNllaFYvdGkSWqp2RZijE88=.a13aae0f-f5a1-4773-92cb-ffccab820d88@github.com>
References: <9H36lIpFiwG4v0oGPE2zCIawMJcNIhuGguz--qxjRnQ=.0fc08ed3-2d12-42d0-8b6c-3fa801d55427@github.com>
 <9DAQ0XpB6JlntsaEu1TZNirVwkT7kewRhKdfeIgoN4s=.d8741a54-876e-4691-9471-a77d392f9ff9@github.com>
 <p6YoUItcvlrz7h08aOZhtNllaFYvdGkSWqp2RZijE88=.a13aae0f-f5a1-4773-92cb-ffccab820d88@github.com>
Message-ID: <nXMvYlSkExBCwB2VsQgzpS2TxjXAWVWvz2HUwwOKwGU=.1b932db4-db45-46ea-9db7-b93d3353aaa5@github.com>

On Thu, 1 Jun 2023 23:14:23 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: use output.shouldContain()
>
> test/jdk/sun/tools/jcmd/TestJcmdNoAgentLoad.java line 57:
> 
>> 55:         OutputAnalyzer output = JcmdBase.jcmd(jcmdArgs);
>> 56: 
>> 57:         assertEquals(output.getExitValue(), 0);
> 
> I think tests normally just use `output.shouldHaveExitValue(0);`

Thank you for the suggestion. I've derived this code from one of the existing jcmd tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14244#discussion_r1213871217

From sspitsyn at openjdk.org  Fri Jun  2 03:20:37 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 2 Jun 2023 03:20:37 GMT
Subject: RFR: 8304438: jcmd JVMTI.agent_load should obey
 EnableDynamicAgentLoading [v5]
In-Reply-To: <9H36lIpFiwG4v0oGPE2zCIawMJcNIhuGguz--qxjRnQ=.0fc08ed3-2d12-42d0-8b6c-3fa801d55427@github.com>
References: <9H36lIpFiwG4v0oGPE2zCIawMJcNIhuGguz--qxjRnQ=.0fc08ed3-2d12-42d0-8b6c-3fa801d55427@github.com>
Message-ID: <SrieQv51JOYj65Ogwf6ZxX7J5fXUtYkQryomL6HGSuw=.309d5a44-2411-4f28-a62f-dafb6b8b55b4@github.com>

> The VM option EnableDynamicAgentLoading was added in JDK 9, default true, to allow deployment to choose whether to allow agents to be loaded/started in the VM. The VM option does the right thing for tools using the Attach API but jcmd JVMTI.agent_load was missed. This should be fixed to disallow loading JVMTI agents when the EnableDynamicAgentLoading is false.
> 
> The CSR is:
> [JDK-8309250](https://bugs.openjdk.org/browse/JDK-8309250): jcmd JVMTI.agent_load should obey EnableDynamicAgentLoading
> 
> Testing:
>  - run new test `test/jdk/sun/tools/jcmd/TestJcmdNoAgentLoad.java`
>  - TBD: submit mach5 tiers 1-5 to make sure no new regressions are introduced

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: use output.shouldHaveExitValue(0) in the test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14244/files
  - new: https://git.openjdk.org/jdk/pull/14244/files/062b3f85..6712f24a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14244&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14244&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14244.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14244/head:pull/14244

PR: https://git.openjdk.org/jdk/pull/14244

From sspitsyn at openjdk.org  Fri Jun  2 03:29:04 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 2 Jun 2023 03:29:04 GMT
Subject: RFR: 8309329: com/sun/jdi/DeferredStepTest.java fails with virtual
 threads due to not waiting for threads to exit
In-Reply-To: <9WLOY1a8lk3w-ZTrN-SUCOQXdwHideyuexQNjKXPJ9M=.2f555619-bcb4-4f30-8d17-97b0147c58e1@github.com>
References: <9WLOY1a8lk3w-ZTrN-SUCOQXdwHideyuexQNjKXPJ9M=.2f555619-bcb4-4f30-8d17-97b0147c58e1@github.com>
Message-ID: <MPs8OXI7YTVNsj20cJhbO5aoYNZgAxs32BppenU2Lzw=.f30f6e34-b793-40c0-8c1d-61cc36cb2b11@github.com>

On Thu, 1 Jun 2023 23:03:47 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Virtual threads are always daemon threads, so tests that previously did not explicitly wait for test threads to exit sometimes fail with virtual threads due to the test exiting before the test threads have exited. A join() for each test thread is needed to fix this issue.
> 
> com/sun/jdi/DeferredStepTest.java is one such tests. I looked at the other com/sun/jdi failures listed in [JDK-8285422](https://bugs.openjdk.org/browse/JDK-8285422) and didn't see any others that might be failing for this same reason.
> 
> I tested locally with `JTREG_TEST_THREAD_FACTORY=Virtual`. I'll also run the appropriate mach5 tier that tests com/sun/jdi with virtual threads.

This looks good modulo the comment from Alex about renaming.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14275#pullrequestreview-1456594772

From sspitsyn at openjdk.org  Fri Jun  2 03:44:48 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 2 Jun 2023 03:44:48 GMT
Subject: RFR: 8304438: jcmd JVMTI.agent_load should obey
 EnableDynamicAgentLoading [v6]
In-Reply-To: <9H36lIpFiwG4v0oGPE2zCIawMJcNIhuGguz--qxjRnQ=.0fc08ed3-2d12-42d0-8b6c-3fa801d55427@github.com>
References: <9H36lIpFiwG4v0oGPE2zCIawMJcNIhuGguz--qxjRnQ=.0fc08ed3-2d12-42d0-8b6c-3fa801d55427@github.com>
Message-ID: <rESCXP1ugGHILSvfIC1tURtbi3d90EEZr0rRuCE6RU0=.8acbcec4-f9f1-4584-b493-6d14edcbbffa@github.com>

> The VM option EnableDynamicAgentLoading was added in JDK 9, default true, to allow deployment to choose whether to allow agents to be loaded/started in the VM. The VM option does the right thing for tools using the Attach API but jcmd JVMTI.agent_load was missed. This should be fixed to disallow loading JVMTI agents when the EnableDynamicAgentLoading is false.
> 
> The CSR is:
> [JDK-8309250](https://bugs.openjdk.org/browse/JDK-8309250): jcmd JVMTI.agent_load should obey EnableDynamicAgentLoading
> 
> Testing:
>  - run new test `test/jdk/sun/tools/jcmd/TestJcmdNoAgentLoad.java`
>  - TBD: submit mach5 tiers 1-5 to make sure no new regressions are introduced

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: use output.shouldHaveExitValue(0) in the test
 - review: use output.shouldContain()
 - move check for EnableDynamicAgentLoading to invoke_Agent_OnAttach
 - minor renaming in new test TestJcmdNoAgentLoad.java
 - 8304438: jcmd JVMTI.agent_load should obey EnableDynamicAgentLoading

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14244/files
  - new: https://git.openjdk.org/jdk/pull/14244/files/6712f24a..18cad064

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14244&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14244&range=04-05

  Stats: 8499 lines in 119 files changed: 7217 ins; 645 del; 637 mod
  Patch: https://git.openjdk.org/jdk/pull/14244.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14244/head:pull/14244

PR: https://git.openjdk.org/jdk/pull/14244

From cjplummer at openjdk.org  Fri Jun  2 04:17:07 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 2 Jun 2023 04:17:07 GMT
Subject: RFR: 8304438: jcmd JVMTI.agent_load should obey
 EnableDynamicAgentLoading [v6]
In-Reply-To: <rESCXP1ugGHILSvfIC1tURtbi3d90EEZr0rRuCE6RU0=.8acbcec4-f9f1-4584-b493-6d14edcbbffa@github.com>
References: <9H36lIpFiwG4v0oGPE2zCIawMJcNIhuGguz--qxjRnQ=.0fc08ed3-2d12-42d0-8b6c-3fa801d55427@github.com>
 <rESCXP1ugGHILSvfIC1tURtbi3d90EEZr0rRuCE6RU0=.8acbcec4-f9f1-4584-b493-6d14edcbbffa@github.com>
Message-ID: <6fBgCBJY5gKKOpNCLfJDaI78LB5xma3LwnXz4t7YDXk=.eebf1635-3c17-4101-9f33-9f234197f478@github.com>

On Fri, 2 Jun 2023 03:44:48 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The VM option EnableDynamicAgentLoading was added in JDK 9, default true, to allow deployment to choose whether to allow agents to be loaded/started in the VM. The VM option does the right thing for tools using the Attach API but jcmd JVMTI.agent_load was missed. This should be fixed to disallow loading JVMTI agents when the EnableDynamicAgentLoading is false.
>> 
>> The CSR is:
>> [JDK-8309250](https://bugs.openjdk.org/browse/JDK-8309250): jcmd JVMTI.agent_load should obey EnableDynamicAgentLoading
>> 
>> Testing:
>>  - run new test `test/jdk/sun/tools/jcmd/TestJcmdNoAgentLoad.java`
>>  - TBD: submit mach5 tiers 1-5 to make sure no new regressions are introduced
>
> 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: use output.shouldHaveExitValue(0) in the test
>  - review: use output.shouldContain()
>  - move check for EnableDynamicAgentLoading to invoke_Agent_OnAttach
>  - minor renaming in new test TestJcmdNoAgentLoad.java
>  - 8304438: jcmd JVMTI.agent_load should obey EnableDynamicAgentLoading

Looks good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14244#pullrequestreview-1456621661

From cjplummer at openjdk.org  Fri Jun  2 04:29:16 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 2 Jun 2023 04:29:16 GMT
Subject: RFR: 8309329: com/sun/jdi/DeferredStepTest.java fails with virtual
 threads due to not waiting for threads to exit [v2]
In-Reply-To: <9WLOY1a8lk3w-ZTrN-SUCOQXdwHideyuexQNjKXPJ9M=.2f555619-bcb4-4f30-8d17-97b0147c58e1@github.com>
References: <9WLOY1a8lk3w-ZTrN-SUCOQXdwHideyuexQNjKXPJ9M=.2f555619-bcb4-4f30-8d17-97b0147c58e1@github.com>
Message-ID: <Sm4fKEg8h3fsNiUBMUHux9A4QG-ABQS2MmG5yozX18g=.a7210451-8547-4fe5-83d0-48ff0c9afa15@github.com>

> Virtual threads are always daemon threads, so tests that previously did not explicitly wait for test threads to exit sometimes fail with virtual threads due to the test exiting before the test threads have exited. A join() for each test thread is needed to fix this issue.
> 
> com/sun/jdi/DeferredStepTest.java is one such tests. I looked at the other com/sun/jdi failures listed in [JDK-8285422](https://bugs.openjdk.org/browse/JDK-8285422) and didn't see any others that might be failing for this same reason.
> 
> I tested locally with `JTREG_TEST_THREAD_FACTORY=Virtual`. I'll also run the appropriate mach5 tier that tests com/sun/jdi with virtual threads.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  some variable renaming

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14275/files
  - new: https://git.openjdk.org/jdk/pull/14275/files/24dfa505..f83cd766

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14275&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14275&range=00-01

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/14275.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14275/head:pull/14275

PR: https://git.openjdk.org/jdk/pull/14275

From thartmann at openjdk.org  Fri Jun  2 05:23:23 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 2 Jun 2023 05:23:23 GMT
Subject: RFR: 8309044: Replace NULL with nullptr,
 final sweep of hotspot code [v2]
In-Reply-To: <PBfTk3H5Reg_JykZaFWInLjp2kSW53CpHouGQ_W7bQc=.851a150c-df49-4775-9ec8-8f3b0702c293@github.com>
References: <3FoMnGeBp8DqkpVb6YGXKxdPsgGz6ej-jrf2U2stVfU=.56a11e19-38dd-420a-a07d-3b025120f194@github.com>
 <PBfTk3H5Reg_JykZaFWInLjp2kSW53CpHouGQ_W7bQc=.851a150c-df49-4775-9ec8-8f3b0702c293@github.com>
Message-ID: <o1nt-C1QddWKQlVeTLXzUVvTg5nWBsT378AVDWLVcn4=.e85df594-ea0f-4c6b-b583-1198100e0ffb@github.com>

On Tue, 30 May 2023 19:15:38 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> A final sweep of Hotspot to remove all re-added NULLs. With only 110 changes I'd appreciate if this was considered trivial.
>
> Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Align
>  - Suggestions

I think if we just rely on reviews, NULLs will slip through again and we would need to have regular cleanup PRs. 

Doug's idea seems simple enough to implement in Skara/jcheck. An alternative to whitelisting would be a warning in the offending PR or a requirement for "special approvement" of such changes (for example, via a Skara command).

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

PR Comment: https://git.openjdk.org/jdk/pull/14198#issuecomment-1573169963

From alanb at openjdk.org  Fri Jun  2 06:00:27 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 2 Jun 2023 06:00:27 GMT
Subject: Integrated: 8307478: Implementation of Prepare to Restrict The Dynamic
 Loading of Agents
In-Reply-To: <MA536Tpr3slk80MYAPS3P9fAsy-QLDNZpvN2pNvUGLA=.e2960455-4580-46f7-992d-39f625dac8cc@github.com>
References: <MA536Tpr3slk80MYAPS3P9fAsy-QLDNZpvN2pNvUGLA=.e2960455-4580-46f7-992d-39f625dac8cc@github.com>
Message-ID: <UTMH4WTFlj7CkAYP_fh5De3WVKIEWN3N7YPRloWgO5I=.aabafbf5-2d86-44c4-8531-640207432fc9@github.com>

On Wed, 10 May 2023 11:12:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is the implementation for JEP 451. There are two parts to this:
> 
> 1. A multi-line warning is printed when a JVM TI or Java agent is loaded into a running VM. For JVM TI, the message is printed to stderr from JvmtiAgent::load. For Java agents, it is printed to System.err (as that may be redirected) in the JPLIS (j.l.instrumentation) implementation. This part includes an update to the JVM TI spec and API docs to require the warning.
> 
> 2. If running with -Djdk.instrument.traceUsage or -Djdk.instrument.traceUsage=true, the calls to the Instrumentation API print a trace message and stack trace.
> 
> Testing: tier1-6

This pull request has now been integrated.

Changeset: 5bd2af26
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5bd2af26e66a863edc670229444b3282ba639563
Stats:     1199 lines in 21 files changed: 941 ins; 99 del; 159 mod

8307478: Implementation of Prepare to Restrict The Dynamic Loading of Agents

Reviewed-by: sspitsyn, cjplummer

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

PR: https://git.openjdk.org/jdk/pull/13899

From sspitsyn at openjdk.org  Fri Jun  2 07:14:23 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 2 Jun 2023 07:14:23 GMT
Subject: RFR: 8309044: Replace NULL with nullptr,
 final sweep of hotspot code [v2]
In-Reply-To: <PBfTk3H5Reg_JykZaFWInLjp2kSW53CpHouGQ_W7bQc=.851a150c-df49-4775-9ec8-8f3b0702c293@github.com>
References: <3FoMnGeBp8DqkpVb6YGXKxdPsgGz6ej-jrf2U2stVfU=.56a11e19-38dd-420a-a07d-3b025120f194@github.com>
 <PBfTk3H5Reg_JykZaFWInLjp2kSW53CpHouGQ_W7bQc=.851a150c-df49-4775-9ec8-8f3b0702c293@github.com>
Message-ID: <T0C7ceFBXRdlYQWDAW-dhaBL2jAjh77GbqIlToq9pdY=.1ca18d5d-bdce-4f67-9764-dfda779538cd@github.com>

On Tue, 30 May 2023 19:15:38 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> A final sweep of Hotspot to remove all re-added NULLs. With only 110 changes I'd appreciate if this was considered trivial.
>
> Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Align
>  - Suggestions

Looks good.
Thanks,
Serguei

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

PR Review: https://git.openjdk.org/jdk/pull/14198#pullrequestreview-1456781527

From stefank at openjdk.org  Fri Jun  2 07:50:21 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 2 Jun 2023 07:50:21 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v4]
In-Reply-To: <2sgbRGVCiStjmAspEqqpyWAM0IzbZfjFC6HHXlhbcyE=.9637c274-1b10-4103-b528-34719037362b@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <2sgbRGVCiStjmAspEqqpyWAM0IzbZfjFC6HHXlhbcyE=.9637c274-1b10-4103-b528-34719037362b@github.com>
Message-ID: <zDRjSpHIoJt8WKy4VPEMfJCMcHt6ZE2FUcyP9-S4auc=.dcacb84f-2415-420d-94af-04ec54189cff@github.com>

On Fri, 2 Jun 2023 02:49:25 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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:
> 
>   Force PLAB sizes to align on card-table size

I've reviewed the shared code and think that looks good.

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14185#pullrequestreview-1456831456

From sgehwolf at openjdk.org  Fri Jun  2 09:01:16 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 2 Jun 2023 09:01:16 GMT
Subject: RFR: 8308090: Add container tests for on-the-fly resource quota
 updates [v2]
In-Reply-To: <wM_d0lw-QV0H7VsCiI0QdOM-PKynxEFgz6wOVSPoJAU=.72b784bf-3656-4551-a3c9-1c33eb748e28@github.com>
References: <w8L1msIb1ImXE3bWx4ZLaX3mg4MH_shRsN3CObIb-Ew=.1841e10b-595a-4bbb-9368-68897e4306df@github.com>
 <wM_d0lw-QV0H7VsCiI0QdOM-PKynxEFgz6wOVSPoJAU=.72b784bf-3656-4551-a3c9-1c33eb748e28@github.com>
Message-ID: <xuXwvEdG6cYFWIhacGp5DOKRaVaza9rqJq8ClRl6-HM=.da8a437f-e72d-4fd8-ac2f-e0f072addd39@github.com>

On Tue, 23 May 2023 09:04:11 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review these test changes which implement automatic testing of container resource updates without JVM restart. Note that this merely tests container detection code handling this case. It doesn't do anything special for the JVM itself, though it might make sense to add some sanity checks should we detect certain limits changing. In another PR, though.
>> 
>> As to the test design, it works similar to the shared temp tests: Interact between the two containers by virtue of a shared filesystem `/tmp` and creating marker files there in order to make them cooperate. Note that the new test needs `podman` version `4.3.0` and better (`4.5` is current).
>> 
>> Testing:
>>  - [x] GHA
>>  - [x] Linux x86_64 container tests on cg v1 and cg v2 system
>>  - [x] Newly added tests on Linux x86_64 cg v1 and cg v2 (`podman` and `docker`)
>
> Severin Gehwolf 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-8308090-tests-container-on-fly-updates
>  - Fix whitespace
>  - 8308090: Add container tests for on-the-fly resource quota updates

Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/14090#issuecomment-1573393329

From sgehwolf at openjdk.org  Fri Jun  2 09:01:19 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 2 Jun 2023 09:01:19 GMT
Subject: Integrated: 8308090: Add container tests for on-the-fly resource quota
 updates
In-Reply-To: <w8L1msIb1ImXE3bWx4ZLaX3mg4MH_shRsN3CObIb-Ew=.1841e10b-595a-4bbb-9368-68897e4306df@github.com>
References: <w8L1msIb1ImXE3bWx4ZLaX3mg4MH_shRsN3CObIb-Ew=.1841e10b-595a-4bbb-9368-68897e4306df@github.com>
Message-ID: <WHycS5_36FTOCyG0h2TsTTzLTnLW7Z0ifjh-6W4LOik=.200393bf-b500-45b1-bd4e-2c0302640491@github.com>

On Mon, 22 May 2023 16:40:40 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review these test changes which implement automatic testing of container resource updates without JVM restart. Note that this merely tests container detection code handling this case. It doesn't do anything special for the JVM itself, though it might make sense to add some sanity checks should we detect certain limits changing. In another PR, though.
> 
> As to the test design, it works similar to the shared temp tests: Interact between the two containers by virtue of a shared filesystem `/tmp` and creating marker files there in order to make them cooperate. Note that the new test needs `podman` version `4.3.0` and better (`4.5` is current).
> 
> Testing:
>  - [x] GHA
>  - [x] Linux x86_64 container tests on cg v1 and cg v2 system
>  - [x] Newly added tests on Linux x86_64 cg v1 and cg v2 (`podman` and `docker`)

This pull request has now been integrated.

Changeset: dc8bc6c9
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dc8bc6c98ca1f9b441cf71c641675fe29dda9162
Stats:     434 lines in 5 files changed: 431 ins; 2 del; 1 mod

8308090: Add container tests for on-the-fly resource quota updates

Reviewed-by: dholmes, mseledtsov

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

PR: https://git.openjdk.org/jdk/pull/14090

From fjiang at openjdk.org  Fri Jun  2 09:35:22 2023
From: fjiang at openjdk.org (Feilong Jiang)
Date: Fri, 2 Jun 2023 09:35:22 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v4]
In-Reply-To: <2sgbRGVCiStjmAspEqqpyWAM0IzbZfjFC6HHXlhbcyE=.9637c274-1b10-4103-b528-34719037362b@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <2sgbRGVCiStjmAspEqqpyWAM0IzbZfjFC6HHXlhbcyE=.9637c274-1b10-4103-b528-34719037362b@github.com>
Message-ID: <9zx2L2htHAAmC0dInZaMaMESDiueZJAn7Tv9XzznJJc=.c3aadf60-97f6-46fe-8bee-a55baeb9bc67@github.com>

On Fri, 2 Jun 2023 02:49:25 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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:
> 
>   Force PLAB sizes to align on card-table size

Hi, I have built this pr based on aa85a90, Tier1 tests failed on `gc/TestAllocHumongousFragment.java#generational` on Linux/RISC-V with the following output:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (shenandoahVerifier.cpp:1244), pid=2951116, tid=2951124
#  Error: Verify init-mark remembered set violation; clean card should be dirty
#
# JRE version: OpenJDK Runtime Environment (21.0) (build 21-internal-adhoc.ubuntu.jdk)
# Java VM: OpenJDK 64-Bit Server VM (21-internal-adhoc.ubuntu.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, shenandoah gc, linux-riscv64)


Looks like Generational Shenandoah does not fully support RISC-V port, should we disable this test on RISC-V port for now?

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

PR Comment: https://git.openjdk.org/jdk/pull/14185#issuecomment-1573436275

From duke at openjdk.org  Fri Jun  2 10:26:30 2023
From: duke at openjdk.org (JoKern65)
Date: Fri, 2 Jun 2023 10:26:30 GMT
Subject: RFR: JDK-8309225: Fix xlc17 clang 15 warnings in security and
 servicability
Message-ID: <TVjM9BfpfntsYda5nA4AcZazR-O8Mjl1SyTFu-Bmtpo=.d407a6a1-a865-49ea-8a58-deba1ba11d0c@github.com>

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))
^

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}

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

Commit messages:
 - JDK-8309225

Changes: https://git.openjdk.org/jdk/pull/14282/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14282&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309225
  Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14282.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14282/head:pull/14282

PR: https://git.openjdk.org/jdk/pull/14282

From lmesnik at openjdk.org  Fri Jun  2 16:33:10 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 2 Jun 2023 16:33:10 GMT
Subject: RFR: 8309329: com/sun/jdi/DeferredStepTest.java fails with virtual
 threads due to not waiting for threads to exit [v2]
In-Reply-To: <Sm4fKEg8h3fsNiUBMUHux9A4QG-ABQS2MmG5yozX18g=.a7210451-8547-4fe5-83d0-48ff0c9afa15@github.com>
References: <9WLOY1a8lk3w-ZTrN-SUCOQXdwHideyuexQNjKXPJ9M=.2f555619-bcb4-4f30-8d17-97b0147c58e1@github.com>
 <Sm4fKEg8h3fsNiUBMUHux9A4QG-ABQS2MmG5yozX18g=.a7210451-8547-4fe5-83d0-48ff0c9afa15@github.com>
Message-ID: <gkgTGQ5MyOAEWi_TJLCClsB7tNSUr3fYdxUmsgS4bxA=.2973a766-d429-438e-9545-0e6195f68f01@github.com>

On Fri, 2 Jun 2023 04:29:16 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Virtual threads are always daemon threads, so tests that previously did not explicitly wait for test threads to exit sometimes fail with virtual threads due to the test exiting before the test threads have exited. A join() for each test thread is needed to fix this issue.
>> 
>> com/sun/jdi/DeferredStepTest.java is one such tests. I looked at the other com/sun/jdi failures listed in [JDK-8285422](https://bugs.openjdk.org/browse/JDK-8285422) and didn't see any others that might be failing for this same reason.
>> 
>> I tested locally with `JTREG_TEST_THREAD_FACTORY=Virtual`. I'll also run the appropriate mach5 tier that tests com/sun/jdi with virtual threads.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   some variable renaming

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14275#pullrequestreview-1457971775

From ysr at openjdk.org  Fri Jun  2 17:59:26 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 2 Jun 2023 17:59:26 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v4]
In-Reply-To: <2sgbRGVCiStjmAspEqqpyWAM0IzbZfjFC6HHXlhbcyE=.9637c274-1b10-4103-b528-34719037362b@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <2sgbRGVCiStjmAspEqqpyWAM0IzbZfjFC6HHXlhbcyE=.9637c274-1b10-4103-b528-34719037362b@github.com>
Message-ID: <sjjq3q_tE5FxtYhZOYahzQfv5efaqf1POmnyeGD11Qc=.cfd6cd88-ec70-4d88-b9e0-2e8ca2732585@github.com>

On Fri, 2 Jun 2023 02:49:25 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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:
> 
>   Force PLAB sizes to align on card-table size

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1285:

> 1283:   if (unalignment != 0) {
> 1284:     word_size = word_size - unalignment + CardTable::card_size_in_words();
> 1285:   }

Probably not a big deal since this is only used when refilling a PLAB, which is an infrequent operation, but `mod` is an expensive operation, in general, and best to avoid in our code except in assertion checks (or even there given recent experiences with debug tests timing out). Since card size is a power of 2, may be we could use addition and masking instead. Something like defining the following inline in the CardTable class and using it everywhere where card alignment granularity is sought. There may even be a macro or method defined for this already perhaps:


(FOO + CardSize - 1) & ~((1 << LogCardSize) - 1)


One could even store the mask to avoid the arithmetic to produce the mask although it's pretty cheap.

This may turn out to be less expensive than mod, test, and branch, but as I said probably not a big deal here. We should make sure we don't overuse mods in our allocation paths much.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1214658808

From mdoerr at openjdk.org  Fri Jun  2 18:13:24 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 2 Jun 2023 18:13:24 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v4]
In-Reply-To: <2sgbRGVCiStjmAspEqqpyWAM0IzbZfjFC6HHXlhbcyE=.9637c274-1b10-4103-b528-34719037362b@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <2sgbRGVCiStjmAspEqqpyWAM0IzbZfjFC6HHXlhbcyE=.9637c274-1b10-4103-b528-34719037362b@github.com>
Message-ID: <TUPolfWktJHjzU42z4pnrWFNn0st_EhVA0TYg6LVBVo=.f9d6a6c7-d5e9-4ff9-811a-dc3a694fb27f@github.com>

On Fri, 2 Jun 2023 02:49:25 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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:
> 
>   Force PLAB sizes to align on card-table size

> #  Internal Error (shenandoahVerifier.cpp:1244), pid=2951116, tid=2951124
> #  Error: Verify init-mark remembered set violation; clean card should be dirty


I've seen the same issue on PPC64: https://bugs.openjdk.org/browse/JDK-8309371

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

PR Comment: https://git.openjdk.org/jdk/pull/14185#issuecomment-1574125489

From ysr at openjdk.org  Fri Jun  2 18:27:21 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 2 Jun 2023 18:27:21 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v4]
In-Reply-To: <2sgbRGVCiStjmAspEqqpyWAM0IzbZfjFC6HHXlhbcyE=.9637c274-1b10-4103-b528-34719037362b@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <2sgbRGVCiStjmAspEqqpyWAM0IzbZfjFC6HHXlhbcyE=.9637c274-1b10-4103-b528-34719037362b@github.com>
Message-ID: <7uARcGDHOuSUugc2zRg7JQgC2dSPBDOjeWGPjBPO2qs=.a09479b8-ba9b-4596-bc5a-7ace0968fe31@github.com>

On Fri, 2 Jun 2023 02:49:25 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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:
> 
>   Force PLAB sizes to align on card-table size

src/hotspot/cpu/riscv/gc/shenandoah/c1/shenandoahBarrierSetC1_riscv.cpp line 4:

> 2:  * Copyright (c) 2018, 2019, 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.

This should be backed out, since it seems that there is no (other) change to this fie.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1214682175

From mdoerr at openjdk.org  Fri Jun  2 18:41:25 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 2 Jun 2023 18:41:25 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v4]
In-Reply-To: <7uARcGDHOuSUugc2zRg7JQgC2dSPBDOjeWGPjBPO2qs=.a09479b8-ba9b-4596-bc5a-7ace0968fe31@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <2sgbRGVCiStjmAspEqqpyWAM0IzbZfjFC6HHXlhbcyE=.9637c274-1b10-4103-b528-34719037362b@github.com>
 <7uARcGDHOuSUugc2zRg7JQgC2dSPBDOjeWGPjBPO2qs=.a09479b8-ba9b-4596-bc5a-7ace0968fe31@github.com>
Message-ID: <95yaqYTYoGnlkrDMbvZ-NTyVbGmHrL4DUYYIlV3wkwQ=.b6d787d2-3858-4486-b3dc-428a87969109@github.com>

On Fri, 2 Jun 2023 18:24:16 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Force PLAB sizes to align on card-table size
>
> src/hotspot/cpu/riscv/gc/shenandoah/c1/shenandoahBarrierSetC1_riscv.cpp line 4:
> 
>> 2:  * Copyright (c) 2018, 2019, 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.
> 
> This should be backed out, since it seems that there is no (other) change to this fie.

Yes. And also from files which were changed by non-Amazon employees only, please.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1214693296

From amenkov at openjdk.org  Fri Jun  2 19:13:13 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 2 Jun 2023 19:13:13 GMT
Subject: RFR: 8309329: com/sun/jdi/DeferredStepTest.java fails with virtual
 threads due to not waiting for threads to exit [v2]
In-Reply-To: <Sm4fKEg8h3fsNiUBMUHux9A4QG-ABQS2MmG5yozX18g=.a7210451-8547-4fe5-83d0-48ff0c9afa15@github.com>
References: <9WLOY1a8lk3w-ZTrN-SUCOQXdwHideyuexQNjKXPJ9M=.2f555619-bcb4-4f30-8d17-97b0147c58e1@github.com>
 <Sm4fKEg8h3fsNiUBMUHux9A4QG-ABQS2MmG5yozX18g=.a7210451-8547-4fe5-83d0-48ff0c9afa15@github.com>
Message-ID: <lpw9ghphzlEPTFmiXhIQ4KiOe-kuWw2ulraiiKRHqSM=.49e09440-5038-412b-a6d4-00a56d7b115e@github.com>

On Fri, 2 Jun 2023 04:29:16 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Virtual threads are always daemon threads, so tests that previously did not explicitly wait for test threads to exit sometimes fail with virtual threads due to the test exiting before the test threads have exited. A join() for each test thread is needed to fix this issue.
>> 
>> com/sun/jdi/DeferredStepTest.java is one such tests. I looked at the other com/sun/jdi failures listed in [JDK-8285422](https://bugs.openjdk.org/browse/JDK-8285422) and didn't see any others that might be failing for this same reason.
>> 
>> I tested locally with `JTREG_TEST_THREAD_FACTORY=Virtual`. I'll also run the appropriate mach5 tier that tests com/sun/jdi with virtual threads.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   some variable renaming

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14275#pullrequestreview-1458344825

From cjplummer at openjdk.org  Fri Jun  2 19:13:16 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 2 Jun 2023 19:13:16 GMT
Subject: Integrated: 8309329: com/sun/jdi/DeferredStepTest.java fails with
 virtual threads due to not waiting for threads to exit
In-Reply-To: <9WLOY1a8lk3w-ZTrN-SUCOQXdwHideyuexQNjKXPJ9M=.2f555619-bcb4-4f30-8d17-97b0147c58e1@github.com>
References: <9WLOY1a8lk3w-ZTrN-SUCOQXdwHideyuexQNjKXPJ9M=.2f555619-bcb4-4f30-8d17-97b0147c58e1@github.com>
Message-ID: <kkPNXcQSuDRXKEt_4NcFV_iM-09xwnloD5lCVl8_XUw=.f1d95d26-4590-4e76-b8d4-f6a4bed927be@github.com>

On Thu, 1 Jun 2023 23:03:47 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Virtual threads are always daemon threads, so tests that previously did not explicitly wait for test threads to exit sometimes fail with virtual threads due to the test exiting before the test threads have exited. A join() for each test thread is needed to fix this issue.
> 
> com/sun/jdi/DeferredStepTest.java is one such tests. I looked at the other com/sun/jdi failures listed in [JDK-8285422](https://bugs.openjdk.org/browse/JDK-8285422) and didn't see any others that might be failing for this same reason.
> 
> I tested locally with `JTREG_TEST_THREAD_FACTORY=Virtual`. I'll also run the appropriate mach5 tier that tests com/sun/jdi with virtual threads.

This pull request has now been integrated.

Changeset: 1bb037bd
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1bb037bdc6cd76a15f85c05d8c1972ac53b9b3cd
Stats:     12 lines in 2 files changed: 9 ins; 1 del; 2 mod

8309329: com/sun/jdi/DeferredStepTest.java fails with virtual threads due to not waiting for threads to exit

Reviewed-by: sspitsyn, lmesnik, amenkov

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

PR: https://git.openjdk.org/jdk/pull/14275

From cjplummer at openjdk.org  Fri Jun  2 19:13:14 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 2 Jun 2023 19:13:14 GMT
Subject: RFR: 8309329: com/sun/jdi/DeferredStepTest.java fails with virtual
 threads due to not waiting for threads to exit [v2]
In-Reply-To: <Sm4fKEg8h3fsNiUBMUHux9A4QG-ABQS2MmG5yozX18g=.a7210451-8547-4fe5-83d0-48ff0c9afa15@github.com>
References: <9WLOY1a8lk3w-ZTrN-SUCOQXdwHideyuexQNjKXPJ9M=.2f555619-bcb4-4f30-8d17-97b0147c58e1@github.com>
 <Sm4fKEg8h3fsNiUBMUHux9A4QG-ABQS2MmG5yozX18g=.a7210451-8547-4fe5-83d0-48ff0c9afa15@github.com>
Message-ID: <DDolH9CvBKgTdtDupKOwo2dl_mdZuh91JTMW82J07I0=.e0f64889-24dc-438b-a85d-eb0699470355@github.com>

On Fri, 2 Jun 2023 04:29:16 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Virtual threads are always daemon threads, so tests that previously did not explicitly wait for test threads to exit sometimes fail with virtual threads due to the test exiting before the test threads have exited. A join() for each test thread is needed to fix this issue.
>> 
>> com/sun/jdi/DeferredStepTest.java is one such tests. I looked at the other com/sun/jdi failures listed in [JDK-8285422](https://bugs.openjdk.org/browse/JDK-8285422) and didn't see any others that might be failing for this same reason.
>> 
>> I tested locally with `JTREG_TEST_THREAD_FACTORY=Virtual`. I'll also run the appropriate mach5 tier that tests com/sun/jdi with virtual threads.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   some variable renaming

Thanks for the reviews Alex, Serguei, and Leonid.

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

PR Comment: https://git.openjdk.org/jdk/pull/14275#issuecomment-1574190569

From amenkov at openjdk.org  Fri Jun  2 19:30:11 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 2 Jun 2023 19:30:11 GMT
Subject: RFR: 8304438: jcmd JVMTI.agent_load should obey
 EnableDynamicAgentLoading [v6]
In-Reply-To: <rESCXP1ugGHILSvfIC1tURtbi3d90EEZr0rRuCE6RU0=.8acbcec4-f9f1-4584-b493-6d14edcbbffa@github.com>
References: <9H36lIpFiwG4v0oGPE2zCIawMJcNIhuGguz--qxjRnQ=.0fc08ed3-2d12-42d0-8b6c-3fa801d55427@github.com>
 <rESCXP1ugGHILSvfIC1tURtbi3d90EEZr0rRuCE6RU0=.8acbcec4-f9f1-4584-b493-6d14edcbbffa@github.com>
Message-ID: <aX9JIq-7SOo2Tyn1j-luKrSYrJgdkXy-1eML1DsP6rM=.5efbb9b8-9492-4560-a816-48d47afc0cd8@github.com>

On Fri, 2 Jun 2023 03:44:48 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The VM option EnableDynamicAgentLoading was added in JDK 9, default true, to allow deployment to choose whether to allow agents to be loaded/started in the VM. The VM option does the right thing for tools using the Attach API but jcmd JVMTI.agent_load was missed. This should be fixed to disallow loading JVMTI agents when the EnableDynamicAgentLoading is false.
>> 
>> The CSR is:
>> [JDK-8309250](https://bugs.openjdk.org/browse/JDK-8309250): jcmd JVMTI.agent_load should obey EnableDynamicAgentLoading
>> 
>> Testing:
>>  - run new test `test/jdk/sun/tools/jcmd/TestJcmdNoAgentLoad.java`
>>  - TBD: submit mach5 tiers 1-5 to make sure no new regressions are introduced
>
> 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: use output.shouldHaveExitValue(0) in the test
>  - review: use output.shouldContain()
>  - move check for EnableDynamicAgentLoading to invoke_Agent_OnAttach
>  - minor renaming in new test TestJcmdNoAgentLoad.java
>  - 8304438: jcmd JVMTI.agent_load should obey EnableDynamicAgentLoading

test/jdk/sun/tools/jcmd/TestJcmdNoAgentLoad.java line 42:

> 40:  * @library /test/lib
> 41:  *
> 42:  * @run main/othervm -XX:-EnableDynamicAgentLoading TestJcmdNoAgentLoad

The test verifies only one scenario. I think we need to test 3 scenarios:
- -XX:-EnableDynamicAgentLoading
- +XX:-EnableDynamicAgentLoading
- default (no EnableDynamicAgentLoading arg)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14244#discussion_r1214741247

From amenkov at openjdk.org  Fri Jun  2 19:30:11 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 2 Jun 2023 19:30:11 GMT
Subject: RFR: 8304438: jcmd JVMTI.agent_load should obey
 EnableDynamicAgentLoading [v6]
In-Reply-To: <aX9JIq-7SOo2Tyn1j-luKrSYrJgdkXy-1eML1DsP6rM=.5efbb9b8-9492-4560-a816-48d47afc0cd8@github.com>
References: <9H36lIpFiwG4v0oGPE2zCIawMJcNIhuGguz--qxjRnQ=.0fc08ed3-2d12-42d0-8b6c-3fa801d55427@github.com>
 <rESCXP1ugGHILSvfIC1tURtbi3d90EEZr0rRuCE6RU0=.8acbcec4-f9f1-4584-b493-6d14edcbbffa@github.com>
 <aX9JIq-7SOo2Tyn1j-luKrSYrJgdkXy-1eML1DsP6rM=.5efbb9b8-9492-4560-a816-48d47afc0cd8@github.com>
Message-ID: <taNZ0M7Z5NRo_t7C4-z07RSo3_w5iPYRWlZDb-ZGw7o=.4161f7cd-b7be-4f1c-b2aa-27e8ca797a45@github.com>

On Fri, 2 Jun 2023 19:23:23 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> 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: use output.shouldHaveExitValue(0) in the test
>>  - review: use output.shouldContain()
>>  - move check for EnableDynamicAgentLoading to invoke_Agent_OnAttach
>>  - minor renaming in new test TestJcmdNoAgentLoad.java
>>  - 8304438: jcmd JVMTI.agent_load should obey EnableDynamicAgentLoading
>
> test/jdk/sun/tools/jcmd/TestJcmdNoAgentLoad.java line 42:
> 
>> 40:  * @library /test/lib
>> 41:  *
>> 42:  * @run main/othervm -XX:-EnableDynamicAgentLoading TestJcmdNoAgentLoad
> 
> The test verifies only one scenario. I think we need to test 3 scenarios:
> - -XX:-EnableDynamicAgentLoading
> - +XX:-EnableDynamicAgentLoading
> - default (no EnableDynamicAgentLoading arg)

I didn't find tests for EnableDynamicAgentLoading for attach API too (to ensure this fix doesn't break it)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14244#discussion_r1214745149

From ysr at openjdk.org  Fri Jun  2 20:15:29 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 2 Jun 2023 20:15:29 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v4]
In-Reply-To: <2sgbRGVCiStjmAspEqqpyWAM0IzbZfjFC6HHXlhbcyE=.9637c274-1b10-4103-b528-34719037362b@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <2sgbRGVCiStjmAspEqqpyWAM0IzbZfjFC6HHXlhbcyE=.9637c274-1b10-4103-b528-34719037362b@github.com>
Message-ID: <9O5Q9i_7sOIZLqYlRGDMhGOkhCS2aZ2_gFObV9LbjdY=.310b660d-a48e-4ba8-b61a-126ef483f5bc@github.com>

On Fri, 2 Jun 2023 02:49:25 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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:
> 
>   Force PLAB sizes to align on card-table size

Thanks for issue reports, for which we are filing JBS tickets as we receive reports, and will be resolving them as we go. The issues reported to us have been filed as issues linked to the JBS ticket for this PR. Reviewers and testers should please feel free to file tickets as they find other issues, given testing notes in the PR, and platforms on which we have inadequate or no testing or coverage. We appreciate the help!

We will be incrementally resolving as many of the reported issues as we are able to, including in follow up PRs as bug fixes as appropriate.

There were some issues reported with copyright headers, and those will be fixed soon in this PR.

Please follow the tickets for further updates.

Many thanks to all the reviewers so far.

I have been a reviewer at the project level for several of the commits that comprise this PR, so I am happy to review and approve this pull request as a reviewer, as well as a project participant and partial implementor for some fixes.

Onwards to the brave new generation of Shenandoah! ;-)

?       ?

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14185#pullrequestreview-1458425985

From cjplummer at openjdk.org  Fri Jun  2 21:48:13 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 2 Jun 2023 21:48:13 GMT
Subject: RFR: 8309397: com/sun/jdi/JdbXXX tests fail due to not being run with
 -Djdk.trackAllThreads
Message-ID: <Rjxov_l1m12SNVarRfEuGYlHKQPl-OC91q6MgtHpkqU=.574a75b5-803d-4a50-8935-225dfd0e193e@github.com>

The com/sun/jdi/JdbXXX tests rely on the jdb "threads" command output to find the main thread. If it is a virtual thread, it will not be included in the "threads" output unless the debuggee is run with -Djdk.trackAllThreads, so we need to make sure to include this option when launching the debuggee. The following tests are impacted.

com/sun/jdi/JdbMethodExitTest.java
com/sun/jdi/JdbStepTest.java
com/sun/jdi/JdbStopThreadTest.java
com/sun/jdi/JdbStopThreadidTest.java

Note that all these tests also fail due to [JDK-8309334](https://bugs.openjdk.org/browse/JDK-8309334), which needs to be fixed first. Also JdbMethodExitTest.java will fail due to [JDK-8309396](https://bugs.openjdk.org/browse/JDK-8309396), which should be fixed after this CR.

I've tested with mach5 tier5 in a workspace that has integrated the various CRs mentioned. Once JDK-8309334 is fixed, before integrating this PR I'll first merge and verify that the 3 tests being removed from the problem list by this PR also pass.

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

Commit messages:
 - Launch debuggee with -Djdk.trackAllThreads

Changes: https://git.openjdk.org/jdk/pull/14293/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14293&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309397
  Stats: 4 lines in 2 files changed: 1 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14293.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14293/head:pull/14293

PR: https://git.openjdk.org/jdk/pull/14293

From cjplummer at openjdk.org  Fri Jun  2 21:49:58 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 2 Jun 2023 21:49:58 GMT
Subject: RFR: 8309397: com/sun/jdi/JdbXXX tests fail due to not being run with
 -Djdk.trackAllThreads
Message-ID: <Rjxov_l1m12SNVarRfEuGYlHKQPl-OC91q6MgtHpkqU=.c7ec0949-5c8c-4604-ac49-9012689a87a7@github.com>

The com/sun/jdi/JdbXXX tests rely on the jdb "threads" command output to find the main thread. If it is a virtual thread, it will not be included in the "threads" output unless the debuggee is run with -Djdk.trackAllThreads, so we need to make sure to include this option when launching the debuggee. The following tests are impacted.

com/sun/jdi/JdbMethodExitTest.java
com/sun/jdi/JdbStepTest.java
com/sun/jdi/JdbStopThreadTest.java
com/sun/jdi/JdbStopThreadidTest.java

Note that all these tests also fail due to [JDK-8309334](https://bugs.openjdk.org/browse/JDK-8309334), which needs to be fixed first. Also JdbMethodExitTest.java will fail due to [JDK-8309396](https://bugs.openjdk.org/browse/JDK-8309396), which should be fixed after this CR.

I've tested with mach5 tier5 in a workspace that has integrated the various CRs mentioned. Once JDK-8309334 is fixed, before integrating this PR I'll first merge and verify that the 3 tests being removed from the problem list by this PR also pass.

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

Commit messages:
 - Launch debuggee with -Djdk.trackAllThreads

Changes: https://git.openjdk.org/jdk/pull/14293/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14293&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309397
  Stats: 4 lines in 2 files changed: 1 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14293.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14293/head:pull/14293

PR: https://git.openjdk.org/jdk/pull/14293

From cjplummer at openjdk.org  Fri Jun  2 21:55:27 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 2 Jun 2023 21:55:27 GMT
Subject: RFR: 8309396: com/sun/jdi/JdbMethodExitTest.java fails with virtual
 threads due to a bug in determining the main thread id
Message-ID: <_rWgi41CJ8newOTI2hqbjeNgOCCDTnNq030O6wXi_RI=.436a6404-306a-4001-b193-1206ee40f85d@github.com>

JdbMethodExitTest.java tries to determine the jdb threadID for the "main" thread, and then later use it in jdb commands that require a threadID. It does this by first having the debuggee execute the following:

        System.out.println("threadid="+Thread.currentThread().getId());

And then later on the test parses the threadID from this output. The problem is that the id returned by getId() has no relation to threadIDs used by jdb, which are actually JDWP ObjectIDs. In the past this has worked due to some dumb luck. getID() always returns 1 for the main thread, which is always the thread we are executing in. Coincidentally the JDWP ObjectID for the main Thread object is also always 1 because this is the first ObjectID that the debug agent ever needs to create. However, when the debuggee main thread is a virtual thread, neither getId() nor JDWP assign 1 to the threadID, and in fact both will end up with very different values for the threadID. The end result is errors from jdb for using an invalid threadID.

The correct threadID can be obtained by executing the jdb "threads" command and parsing it from a line that looks like the following:

   (java.lang.VirtualThread)694 main running (at breakpoint)

Note this test will also fail due to [JDK-8309334](https://bugs.openjdk.org/browse/JDK-8309334) and [JDK-8309397](https://bugs.openjdk.org/browse/JDK-8309397), which should be fixed first. 

I've tested with mach5 tier5 in a workspace that has integrated the various CRs mentioned. Once JDK-8309334 and JDK-8309397 are fixed, before integrating this PR I'll first merge and verify that the test being removed from the problem list by this PR also passes.

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

Commit messages:
 - remove test from problem list
 - properly determine the main threadId

Changes: https://git.openjdk.org/jdk/pull/14294/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14294&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309396
  Stats: 11 lines in 2 files changed: 5 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14294.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14294/head:pull/14294

PR: https://git.openjdk.org/jdk/pull/14294

From amenkov at openjdk.org  Fri Jun  2 22:05:16 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 2 Jun 2023 22:05:16 GMT
Subject: Integrated: 8308978: regression with a deadlock involving
 FollowReferences
In-Reply-To: <2J1qItzUgmfjRPS0xUbHgXZQ-b12JBxe8XPRftU2GyA=.025e7855-5df4-413a-bea7-585a53832025@github.com>
References: <2J1qItzUgmfjRPS0xUbHgXZQ-b12JBxe8XPRftU2GyA=.025e7855-5df4-413a-bea7-585a53832025@github.com>
Message-ID: <EmUK-NApf1gj8afzFJjXzYVwyxOemkLZf-JBRcxcHQo=.fd9abf30-6ab2-47f3-9839-81c3d5ef7774@github.com>

On Tue, 30 May 2023 22:58:58 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes regression from JDK-8299414.
> There is a deadlock between JvmtiVTMSTransitionDisabler and EscapeBarrier when virtual threads are in mount/unmount transition:
> EscapeBarrier requests deoptimization which requires thread suspension.
> JvmtiVTMSTransitionDisabler ctor waits until all in progress VTMS transitions complete, but they cannot be completed as thread is suspended.
> To avoid the deadlock mount/unmount transitions should be completed before EscapeBarrier stuff.

This pull request has now been integrated.

Changeset: 62c935d4
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/62c935d4fa09ed557d301bc28d9bf1480b344989
Stats:     22 lines in 2 files changed: 6 ins; 16 del; 0 mod

8308978: regression with a deadlock involving FollowReferences

Reviewed-by: sspitsyn, lmesnik

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

PR: https://git.openjdk.org/jdk/pull/14233

From cjplummer at openjdk.org  Fri Jun  2 22:32:14 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 2 Jun 2023 22:32:14 GMT
Subject: RFR: 8309391: Remove non-failing tests from
 test/jdk/ProblemList-Virtual.txt
Message-ID: <-SNTXZ_30agcgbvnhSKMSP_3mBhTrt_rC0IHwIBQ7I0=.24fa8e1d-3c7b-4020-bcb0-a80c45aa03d5@github.com>

The following two tests no longer seem to be failing with the virtual thread test factory:

com/sun/jdi/RedefineG.java 8285422 generic-all
com/sun/jdi/RedefineTTYLineNumber.java 8285422 generic-all

They can be removed from the problem list. I also updated a couple of entries to refer to existing CRs that give more specific reasons for why the tests are failing.

I tested locally using JTREG_TEST_THREAD_FACTORY=Virtual. I also have a mach5 tier5 job in progress that will do all the virtual thread testing.

I'd like to push this as a trivial change.

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

Commit messages:
 - remove some non-failings tests from problem list

Changes: https://git.openjdk.org/jdk/pull/14290/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14290&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309391
  Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14290.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14290/head:pull/14290

PR: https://git.openjdk.org/jdk/pull/14290

From amenkov at openjdk.org  Fri Jun  2 23:00:08 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 2 Jun 2023 23:00:08 GMT
Subject: RFR: 8309334: ProcessTools.main() does not properly set thread
 names when using the virtual thread wrapper
In-Reply-To: <XLb77me5yAoyjBpY1EB8IFjygXP8_5dOgeCCql63y_k=.c061924e-46ac-49df-9df0-62cd5048aaaa@github.com>
References: <XLb77me5yAoyjBpY1EB8IFjygXP8_5dOgeCCql63y_k=.c061924e-46ac-49df-9df0-62cd5048aaaa@github.com>
Message-ID: <zPkh-6t3tcheVcJkrDjmV6NQOZsBe7YFV-7DNr46oxg=.be056d77-c2bd-4679-a604-fc6ad33a40b7@github.com>

On Fri, 2 Jun 2023 21:30:46 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Normally when a virtual thread wrapper is used to run a test, the main thread is renamed to "old-m-a-i-n" and the new virtual thread that will act as the main thread is named "main". Neither is being done by `ProcessTools.main()`. This can cause problems for tests that expect the main thread that the test is running in to be called "main". It is instead left unnamed. This is causing the following 4 tests to fail:
> 
> com/sun/jdi/JdbMethodExitTest.java
> com/sun/jdi/JdbStepTest.java
> com/sun/jdi/JdbStopThreadTest.java
> com/sun/jdi/JdbStopThreadidTest.java
> 
> These tests also fail due to [JDK-8309397](https://bugs.openjdk.org/browse/JDK-8309397), which will be fixed after this CR, and also com/sun/jdi/JdbMethodExitTest.java fails due to [JDK-8309396](https://bugs.openjdk.org/browse/JDK-8309396), which will also subsequently be fixed.
> 
> Note this fix messed up one runtime test. It was expecting an exception message to mention the "main" thread rather than "old-m-a-i-n". Loosening the exception message matching pattern a bit solved the problem.
> 
> Testing was done by running all of tier1 and tier5.

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14292#pullrequestreview-1458569741

From amenkov at openjdk.org  Fri Jun  2 23:08:05 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 2 Jun 2023 23:08:05 GMT
Subject: RFR: 8309396: com/sun/jdi/JdbMethodExitTest.java fails with
 virtual threads due to a bug in determining the main thread id
In-Reply-To: <_rWgi41CJ8newOTI2hqbjeNgOCCDTnNq030O6wXi_RI=.436a6404-306a-4001-b193-1206ee40f85d@github.com>
References: <_rWgi41CJ8newOTI2hqbjeNgOCCDTnNq030O6wXi_RI=.436a6404-306a-4001-b193-1206ee40f85d@github.com>
Message-ID: <gmAaefD-5tc5NCjpg8kAMlPTcfT8fVDRp4-SaaWJScg=.2804832a-10fd-4735-ba74-b78c201dd32d@github.com>

On Fri, 2 Jun 2023 21:47:47 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> JdbMethodExitTest.java tries to determine the jdb threadID for the "main" thread, and then later use it in jdb commands that require a threadID. It does this by first having the debuggee execute the following:
> 
>         System.out.println("threadid="+Thread.currentThread().getId());
> 
> And then later on the test parses the threadID from this output. The problem is that the id returned by getId() has no relation to threadIDs used by jdb, which are actually JDWP ObjectIDs. In the past this has worked due to some dumb luck. getID() always returns 1 for the main thread, which is always the thread we are executing in. Coincidentally the JDWP ObjectID for the main Thread object is also always 1 because this is the first ObjectID that the debug agent ever needs to create. However, when the debuggee main thread is a virtual thread, neither getId() nor JDWP assign 1 to the threadID, and in fact both will end up with very different values for the threadID. The end result is errors from jdb for using an invalid threadID.
> 
> The correct threadID can be obtained by executing the jdb "threads" command and parsing it from a line that looks like the following:
> 
>    (java.lang.VirtualThread)694 main running (at breakpoint)
> 
> Note this test will also fail due to [JDK-8309334](https://bugs.openjdk.org/browse/JDK-8309334) and [JDK-8309397](https://bugs.openjdk.org/browse/JDK-8309397), which should be fixed first. 
> 
> I've tested with mach5 tier5 in a workspace that has integrated the various CRs mentioned. Once JDK-8309334 and JDK-8309397 are fixed, before integrating this PR I'll first merge and verify that the test being removed from the problem list by this PR also passes.

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14294#pullrequestreview-1458578358

From dcubed at openjdk.org  Fri Jun  2 23:36:04 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 2 Jun 2023 23:36:04 GMT
Subject: RFR: 8309391: Remove non-failing tests from
 test/jdk/ProblemList-Virtual.txt
In-Reply-To: <-SNTXZ_30agcgbvnhSKMSP_3mBhTrt_rC0IHwIBQ7I0=.24fa8e1d-3c7b-4020-bcb0-a80c45aa03d5@github.com>
References: <-SNTXZ_30agcgbvnhSKMSP_3mBhTrt_rC0IHwIBQ7I0=.24fa8e1d-3c7b-4020-bcb0-a80c45aa03d5@github.com>
Message-ID: <nNUV7vSEnZH_xtWJ2CGhsCKp-T9nMqzZRhm4Yb9CALQ=.655edde2-ca3a-48e3-bbd7-bc3d84ec1937@github.com>

On Fri, 2 Jun 2023 20:08:15 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The following two tests no longer seem to be failing with the virtual thread test factory:
> 
> com/sun/jdi/RedefineG.java 8285422 generic-all
> com/sun/jdi/RedefineTTYLineNumber.java 8285422 generic-all
> 
> They can be removed from the problem list. I also updated a couple of entries to refer to existing CRs that give more specific reasons for why the tests are failing.
> 
> I tested locally using JTREG_TEST_THREAD_FACTORY=Virtual. I also have a mach5 tier5 job in progress that will do all the virtual thread testing.
> 
> I'd like to push this as a trivial change.

Thumbs up. This is a trivial fix.

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

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14290#pullrequestreview-1458595858

From lmesnik at openjdk.org  Sat Jun  3 01:11:03 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 3 Jun 2023 01:11:03 GMT
Subject: RFR: 8309334: ProcessTools.main() does not properly set thread
 names when using the virtual thread wrapper
In-Reply-To: <XLb77me5yAoyjBpY1EB8IFjygXP8_5dOgeCCql63y_k=.c061924e-46ac-49df-9df0-62cd5048aaaa@github.com>
References: <XLb77me5yAoyjBpY1EB8IFjygXP8_5dOgeCCql63y_k=.c061924e-46ac-49df-9df0-62cd5048aaaa@github.com>
Message-ID: <qWVQNo9OnOEfp2Ugqsp8RKYaIuZXBo6yfeUhHqNcqa8=.1c081866-795e-4ed1-b449-5972e7f365c7@github.com>

On Fri, 2 Jun 2023 21:30:46 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Normally when a virtual thread wrapper is used to run a test, the main thread is renamed to "old-m-a-i-n" and the new virtual thread that will act as the main thread is named "main". Neither is being done by `ProcessTools.main()`. This can cause problems for tests that expect the main thread that the test is running in to be called "main". It is instead left unnamed. This is causing the following 4 tests to fail:
> 
> com/sun/jdi/JdbMethodExitTest.java
> com/sun/jdi/JdbStepTest.java
> com/sun/jdi/JdbStopThreadTest.java
> com/sun/jdi/JdbStopThreadidTest.java
> 
> These tests also fail due to [JDK-8309397](https://bugs.openjdk.org/browse/JDK-8309397), which will be fixed after this CR, and also com/sun/jdi/JdbMethodExitTest.java fails due to [JDK-8309396](https://bugs.openjdk.org/browse/JDK-8309396), which will also subsequently be fixed.
> 
> Note this fix messed up one runtime test. It was expecting an exception message to mention the "main" thread rather than "old-m-a-i-n". Loosening the exception message matching pattern a bit solved the problem.
> 
> Testing was done by running all of tier1 and tier5.

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14292#pullrequestreview-1458712928

From lmesnik at openjdk.org  Sat Jun  3 01:12:04 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 3 Jun 2023 01:12:04 GMT
Subject: RFR: 8309391: Remove non-failing tests from
 test/jdk/ProblemList-Virtual.txt
In-Reply-To: <-SNTXZ_30agcgbvnhSKMSP_3mBhTrt_rC0IHwIBQ7I0=.24fa8e1d-3c7b-4020-bcb0-a80c45aa03d5@github.com>
References: <-SNTXZ_30agcgbvnhSKMSP_3mBhTrt_rC0IHwIBQ7I0=.24fa8e1d-3c7b-4020-bcb0-a80c45aa03d5@github.com>
Message-ID: <hqmXX3aPKgc3kOj0r5tcs9kYDhsjzCydB9ycCENOZdU=.e29a66f3-fd76-4f99-aac4-993a8f59127c@github.com>

On Fri, 2 Jun 2023 20:08:15 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The following two tests no longer seem to be failing with the virtual thread test factory:
> 
> com/sun/jdi/RedefineG.java 8285422 generic-all
> com/sun/jdi/RedefineTTYLineNumber.java 8285422 generic-all
> 
> They can be removed from the problem list. I also updated a couple of entries to refer to existing CRs that give more specific reasons for why the tests are failing.
> 
> I tested locally using JTREG_TEST_THREAD_FACTORY=Virtual. I also have a mach5 tier5 job in progress that will do all the virtual thread testing.
> 
> I'd like to push this as a trivial change.

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14290#pullrequestreview-1458715315

From alanb at openjdk.org  Sat Jun  3 07:13:03 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 3 Jun 2023 07:13:03 GMT
Subject: RFR: 8309397: com/sun/jdi/JdbXXX tests fail due to not being run
 with -Djdk.trackAllThreads
In-Reply-To: <Rjxov_l1m12SNVarRfEuGYlHKQPl-OC91q6MgtHpkqU=.c7ec0949-5c8c-4604-ac49-9012689a87a7@github.com>
References: <Rjxov_l1m12SNVarRfEuGYlHKQPl-OC91q6MgtHpkqU=.c7ec0949-5c8c-4604-ac49-9012689a87a7@github.com>
Message-ID: <zLljVXYvUWFxOBlrawDfp_wHOQMLhyXnk6dAvDBXW2w=.387c5460-2d1b-499b-88a3-9bfbcc2dabc6@github.com>

On Fri, 2 Jun 2023 21:41:32 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The com/sun/jdi/JdbXXX tests rely on the jdb "threads" command output to find the main thread. If it is a virtual thread, it will not be included in the "threads" output unless the debuggee is run with -Djdk.trackAllThreads, so we need to make sure to include this option when launching the debuggee. The following tests are impacted.
> 
> com/sun/jdi/JdbMethodExitTest.java
> com/sun/jdi/JdbStepTest.java
> com/sun/jdi/JdbStopThreadTest.java
> com/sun/jdi/JdbStopThreadidTest.java
> 
> Note that all these tests also fail due to [JDK-8309334](https://bugs.openjdk.org/browse/JDK-8309334), which needs to be fixed first. Also JdbMethodExitTest.java will fail due to [JDK-8309396](https://bugs.openjdk.org/browse/JDK-8309396), which should be fixed after this CR.
> 
> I've tested with mach5 tier5 in a workspace that has integrated the various CRs mentioned. Once JDK-8309334 is fixed, before integrating this PR I'll first merge and verify that the 3 tests being removed from the problem list by this PR also pass.

Would it be possible to expand a bit on why jdk.trackAllThreads is needed? I would have expected jdb "threads" command to be sensitive to whether the debuggee is launched with the JDWP includevirtualthreads option but jdk.trackAllThreads isn't used by the JDWP agent, it is instead used to determine if virtual threads created directly with the Thread API show up in thread dumps or not.

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

PR Comment: https://git.openjdk.org/jdk/pull/14293#issuecomment-1574736478

From sspitsyn at openjdk.org  Sat Jun  3 11:25:23 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 3 Jun 2023 11:25:23 GMT
Subject: RFR: 8307153: JVMTI GetThreadState on carrier should return
 STATE_WAITING
Message-ID: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>

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

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

Commit messages:
 - minor tweaks in libThreadStateTest.cpp
 - 8307153: JVMTI GetThreadState on carrier should return STATE_WAITING

Changes: https://git.openjdk.org/jdk/pull/14298/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14298&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307153
  Stats: 71 lines in 4 files changed: 61 ins; 0 del; 10 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

From alanb at openjdk.org  Sat Jun  3 14:11:05 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 3 Jun 2023 14:11:05 GMT
Subject: RFR: 8309334: ProcessTools.main() does not properly set thread
 names when using the virtual thread wrapper
In-Reply-To: <XLb77me5yAoyjBpY1EB8IFjygXP8_5dOgeCCql63y_k=.c061924e-46ac-49df-9df0-62cd5048aaaa@github.com>
References: <XLb77me5yAoyjBpY1EB8IFjygXP8_5dOgeCCql63y_k=.c061924e-46ac-49df-9df0-62cd5048aaaa@github.com>
Message-ID: <zpcRx0syiflc3q7qlJ8TOXzJN8zbHmMZMNx858Y2IjE=.d0c5c84c-b497-460d-aca3-e1c7ce98162e@github.com>

On Fri, 2 Jun 2023 21:30:46 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Normally when a virtual thread wrapper is used to run a test, the main thread is renamed to "old-m-a-i-n" and the new virtual thread that will act as the main thread is named "main". Neither is being done by `ProcessTools.main()`. This can cause problems for tests that expect the main thread that the test is running in to be called "main". It is instead left unnamed. This is causing the following 4 tests to fail:
> 
> com/sun/jdi/JdbMethodExitTest.java
> com/sun/jdi/JdbStepTest.java
> com/sun/jdi/JdbStopThreadTest.java
> com/sun/jdi/JdbStopThreadidTest.java
> 
> These tests also fail due to [JDK-8309397](https://bugs.openjdk.org/browse/JDK-8309397), which will be fixed after this CR, and also com/sun/jdi/JdbMethodExitTest.java fails due to [JDK-8309396](https://bugs.openjdk.org/browse/JDK-8309396), which will also subsequently be fixed.
> 
> Note this fix messed up one runtime test. It was expecting an exception message to mention the "main" thread rather than "old-m-a-i-n". Loosening the exception message matching pattern a bit solved the problem.
> 
> Testing was done by running all of tier1 and tier5.

test/lib/jdk/test/lib/process/ProcessTools.java line 899:

> 897:             // when main is executed in virtual thread
> 898:             MainThreadGroup tg = new MainThreadGroup();
> 899:             Thread vthread = createVirtualThread(() -> {

You can replace this with `Thread.ofVirtual().unstarted(() -> {` and remove the helper method. I think that helper method dates from the jtreg wrapper solution.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14292#discussion_r1215549528

From ysr at openjdk.org  Sat Jun  3 15:21:22 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Sat, 3 Jun 2023 15:21:22 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v4]
In-Reply-To: <95yaqYTYoGnlkrDMbvZ-NTyVbGmHrL4DUYYIlV3wkwQ=.b6d787d2-3858-4486-b3dc-428a87969109@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <2sgbRGVCiStjmAspEqqpyWAM0IzbZfjFC6HHXlhbcyE=.9637c274-1b10-4103-b528-34719037362b@github.com>
 <7uARcGDHOuSUugc2zRg7JQgC2dSPBDOjeWGPjBPO2qs=.a09479b8-ba9b-4596-bc5a-7ace0968fe31@github.com>
 <95yaqYTYoGnlkrDMbvZ-NTyVbGmHrL4DUYYIlV3wkwQ=.b6d787d2-3858-4486-b3dc-428a87969109@github.com>
Message-ID: <-jrieUm3r32vA5At0baw1nTndtNGoxG6EBrcEDjwyZw=.0a95dc08-1259-418d-a9bb-b2ba86b18c51@github.com>

On Fri, 2 Jun 2023 18:38:41 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/gc/shenandoah/c1/shenandoahBarrierSetC1_riscv.cpp line 4:
>> 
>>> 2:  * Copyright (c) 2018, 2019, 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.
>> 
>> This should be backed out, since it seems that there is no (other) change to this fie.
>
> Yes. And also from files which were changed by non-Amazon employees only, please.

Thanks, Martin. Yes, we have noted that there were a few other files that were inadvertently caught in a copyright header dragnet. These will be reviewed and fixed in https://bugs.openjdk.org/browse/JDK-8309392 .

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1215600873

From cjplummer at openjdk.org  Sat Jun  3 18:24:04 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 3 Jun 2023 18:24:04 GMT
Subject: RFR: 8309334: ProcessTools.main() does not properly set thread
 names when using the virtual thread wrapper
In-Reply-To: <zpcRx0syiflc3q7qlJ8TOXzJN8zbHmMZMNx858Y2IjE=.d0c5c84c-b497-460d-aca3-e1c7ce98162e@github.com>
References: <XLb77me5yAoyjBpY1EB8IFjygXP8_5dOgeCCql63y_k=.c061924e-46ac-49df-9df0-62cd5048aaaa@github.com>
 <zpcRx0syiflc3q7qlJ8TOXzJN8zbHmMZMNx858Y2IjE=.d0c5c84c-b497-460d-aca3-e1c7ce98162e@github.com>
Message-ID: <1BSXXnlH2oe9TenR2t-oiwJAqWlrEjyhSZk_fht2SDE=.d27a4cd5-1b74-4974-8f51-4f73816fcb98@github.com>

On Sat, 3 Jun 2023 14:07:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Normally when a virtual thread wrapper is used to run a test, the main thread is renamed to "old-m-a-i-n" and the new virtual thread that will act as the main thread is named "main". Neither is being done by `ProcessTools.main()`. This can cause problems for tests that expect the main thread that the test is running in to be called "main". It is instead left unnamed. This is causing the following 4 tests to fail:
>> 
>> com/sun/jdi/JdbMethodExitTest.java
>> com/sun/jdi/JdbStepTest.java
>> com/sun/jdi/JdbStopThreadTest.java
>> com/sun/jdi/JdbStopThreadidTest.java
>> 
>> These tests also fail due to [JDK-8309397](https://bugs.openjdk.org/browse/JDK-8309397), which will be fixed after this CR, and also com/sun/jdi/JdbMethodExitTest.java fails due to [JDK-8309396](https://bugs.openjdk.org/browse/JDK-8309396), which will also subsequently be fixed.
>> 
>> Note this fix messed up one runtime test. It was expecting an exception message to mention the "main" thread rather than "old-m-a-i-n". Loosening the exception message matching pattern a bit solved the problem.
>> 
>> Testing was done by running all of tier1 and tier5.
>
> test/lib/jdk/test/lib/process/ProcessTools.java line 899:
> 
>> 897:             // when main is executed in virtual thread
>> 898:             MainThreadGroup tg = new MainThreadGroup();
>> 899:             Thread vthread = createVirtualThread(() -> {
> 
> You can replace this with `Thread.ofVirtual().unstarted(() -> {` and remove the helper method. I think that helper method dates from the jtreg wrapper solution. Better still, maybe you could use `Thread.ofVirtual().name("main").start(() -> {`.

Yes, I already brought this up with Leonid. I was going to file a separate bug for it, but I can fix it with this CR if you'd like.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14292#discussion_r1215705793

From cjplummer at openjdk.org  Sat Jun  3 19:02:04 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 3 Jun 2023 19:02:04 GMT
Subject: RFR: 8309397: com/sun/jdi/JdbXXX tests fail due to not being run
 with -Djdk.trackAllThreads
In-Reply-To: <zLljVXYvUWFxOBlrawDfp_wHOQMLhyXnk6dAvDBXW2w=.387c5460-2d1b-499b-88a3-9bfbcc2dabc6@github.com>
References: <Rjxov_l1m12SNVarRfEuGYlHKQPl-OC91q6MgtHpkqU=.c7ec0949-5c8c-4604-ac49-9012689a87a7@github.com>
 <zLljVXYvUWFxOBlrawDfp_wHOQMLhyXnk6dAvDBXW2w=.387c5460-2d1b-499b-88a3-9bfbcc2dabc6@github.com>
Message-ID: <bqqUAEdMlqCx_2GepxPYY7pb-_-S-97hUdU6pbUK0wc=.17789771-2909-43f0-acbf-e933af44dcb5@github.com>

On Sat, 3 Jun 2023 07:09:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Would it be possible to expand a bit on why jdk.trackAllThreads is needed? I would have expected jdb "threads" command to be sensitive to whether the debuggee is launched with the JDWP includevirtualthreads option but jdk.trackAllThreads isn't used by the JDWP agent, it is instead used to determine if virtual threads created directly with the Thread API show up in thread dumps or not.

I think you are right that this change should not be needed. I was working on addressing a number of different issues with launching debuggees properly and the tests being able to discover virtual threads, and I think maybe I had done this "fix" at some point, and then did [JDK-8309334](https://bugs.openjdk.org/browse/JDK-8309334), (and [JDK-8309396](https://bugs.openjdk.org/browse/JDK-8309396)), and thought that this fix was still needed. I thought for sure it was helping, but I've removed it and the tests still seem to pass with just JDK-8309334 and JDK-8309396.

jdb by default does not track all virtual threads. It does have a a `-trackallthreads` command line option, which triggers passing `includevirtualthreads=y` to the debug agent (assuming jdb is actually doing the launching and not just attaching). However, given that these tests do not pass `includevirtualthreads=y`, I didn't find myself wondering how they were passing after just fixing [JDK-8309334](https://bugs.openjdk.org/browse/JDK-8309334). The answer is that jdb does track any virtual thread that it gets an event for, so as it turns out when these 4 jdb tests look for a specific thread in the `threads` output, it's always a thread that jdb already learned about via an event. I might do a separate PR just to force either  `-trackallthreads` or `includevirtualthreads=y`, but currently that doesn't seem to be needed by any of the jdb tests.

So I think I should close this PR and update the [JDK-8309334](https://bugs.openjdk.org/browse/JDK-8309334) PR to remove the 3 tests that seem to pass with it and don't also need this PR to pass. The 4th test `com/sun/jdi/JdbMethodExitTest.java` needs an additional fix that I need to push separately.

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

PR Comment: https://git.openjdk.org/jdk/pull/14293#issuecomment-1575129126

From cjplummer at openjdk.org  Sat Jun  3 20:29:13 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 3 Jun 2023 20:29:13 GMT
Subject: RFR: 8309391: Remove non-failing tests from
 test/jdk/ProblemList-Virtual.txt
In-Reply-To: <-SNTXZ_30agcgbvnhSKMSP_3mBhTrt_rC0IHwIBQ7I0=.24fa8e1d-3c7b-4020-bcb0-a80c45aa03d5@github.com>
References: <-SNTXZ_30agcgbvnhSKMSP_3mBhTrt_rC0IHwIBQ7I0=.24fa8e1d-3c7b-4020-bcb0-a80c45aa03d5@github.com>
Message-ID: <F_tcKCP3q04Quf1VPjGstPy9CSM_038BOSro4NmeFeE=.4d08096c-b648-4dd6-8547-453b6e847a74@github.com>

On Fri, 2 Jun 2023 20:08:15 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The following two tests no longer seem to be failing with the virtual thread test factory:
> 
> com/sun/jdi/RedefineG.java 8285422 generic-all
> com/sun/jdi/RedefineTTYLineNumber.java 8285422 generic-all
> 
> They can be removed from the problem list. I also updated a couple of entries to refer to existing CRs that give more specific reasons for why the tests are failing.
> 
> I tested locally using JTREG_TEST_THREAD_FACTORY=Virtual. I also have a mach5 tier5 job in progress that will do all the virtual thread testing.
> 
> I'd like to push this as a trivial change.

Thanks for the reviews Dan and Leonid!

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

PR Comment: https://git.openjdk.org/jdk/pull/14290#issuecomment-1575176851

From cjplummer at openjdk.org  Sat Jun  3 20:29:13 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 3 Jun 2023 20:29:13 GMT
Subject: Integrated: 8309391: Remove non-failing tests from
 test/jdk/ProblemList-Virtual.txt
In-Reply-To: <-SNTXZ_30agcgbvnhSKMSP_3mBhTrt_rC0IHwIBQ7I0=.24fa8e1d-3c7b-4020-bcb0-a80c45aa03d5@github.com>
References: <-SNTXZ_30agcgbvnhSKMSP_3mBhTrt_rC0IHwIBQ7I0=.24fa8e1d-3c7b-4020-bcb0-a80c45aa03d5@github.com>
Message-ID: <LPSBhj4JcNtWd1GFx1DXxCeOCYLS7r6hH0PuPj6aUgg=.abc06162-ca06-42f7-8122-d2253a6ac745@github.com>

On Fri, 2 Jun 2023 20:08:15 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The following two tests no longer seem to be failing with the virtual thread test factory:
> 
> com/sun/jdi/RedefineG.java 8285422 generic-all
> com/sun/jdi/RedefineTTYLineNumber.java 8285422 generic-all
> 
> They can be removed from the problem list. I also updated a couple of entries to refer to existing CRs that give more specific reasons for why the tests are failing.
> 
> I tested locally using JTREG_TEST_THREAD_FACTORY=Virtual. I also have a mach5 tier5 job in progress that will do all the virtual thread testing.
> 
> I'd like to push this as a trivial change.

This pull request has now been integrated.

Changeset: fdb5893b
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fdb5893bf0ad277dbaa2aaffb76478d808d2431d
Stats:     4 lines in 1 file changed: 0 ins; 2 del; 2 mod

8309391: Remove non-failing tests from test/jdk/ProblemList-Virtual.txt

Reviewed-by: dcubed, lmesnik

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

PR: https://git.openjdk.org/jdk/pull/14290

From cjplummer at openjdk.org  Sat Jun  3 21:18:23 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 3 Jun 2023 21:18:23 GMT
Subject: RFR: 8309334: ProcessTools.main() does not properly set thread
 names when using the virtual thread wrapper [v2]
In-Reply-To: <XLb77me5yAoyjBpY1EB8IFjygXP8_5dOgeCCql63y_k=.c061924e-46ac-49df-9df0-62cd5048aaaa@github.com>
References: <XLb77me5yAoyjBpY1EB8IFjygXP8_5dOgeCCql63y_k=.c061924e-46ac-49df-9df0-62cd5048aaaa@github.com>
Message-ID: <Ew_43CoITkOIENp21RASOJ1eglugBKIc6oCc8c_Bvkw=.3396be5c-7fe5-4a61-bcb5-b56508139602@github.com>

> Normally when a virtual thread wrapper is used to run a test, the main thread is renamed to "old-m-a-i-n" and the new virtual thread that will act as the main thread is named "main". Neither is being done by `ProcessTools.main()`. This can cause problems for tests that expect the main thread that the test is running in to be called "main". It is instead left unnamed. This is causing the following 4 tests to fail:
> 
> com/sun/jdi/JdbMethodExitTest.java
> com/sun/jdi/JdbStepTest.java
> com/sun/jdi/JdbStopThreadTest.java
> com/sun/jdi/JdbStopThreadidTest.java
> 
> These tests also fail due to [JDK-8309397](https://bugs.openjdk.org/browse/JDK-8309397), which will be fixed after this CR, and also com/sun/jdi/JdbMethodExitTest.java fails due to [JDK-8309396](https://bugs.openjdk.org/browse/JDK-8309396), which will also subsequently be fixed.
> 
> Note this fix messed up one runtime test. It was expecting an exception message to mention the "main" thread rather than "old-m-a-i-n". Loosening the exception message matching pattern a bit solved the problem.
> 
> Testing was done by running all of tier1 and tier5.

Chris Plummer 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 two additional commits since the last revision:

 - Merge branch 'master' into 8309334_processtools
   merge
 - when using virtual threads, properly name the main threads

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14292/files
  - new: https://git.openjdk.org/jdk/pull/14292/files/e53abaf4..de5ca147

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14292&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14292&range=00-01

  Stats: 4052 lines in 65 files changed: 3213 ins; 625 del; 214 mod
  Patch: https://git.openjdk.org/jdk/pull/14292.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14292/head:pull/14292

PR: https://git.openjdk.org/jdk/pull/14292

From cjplummer at openjdk.org  Sat Jun  3 21:34:16 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 3 Jun 2023 21:34:16 GMT
Subject: RFR: 8309334: ProcessTools.main() does not properly set thread
 names when using the virtual thread wrapper [v3]
In-Reply-To: <XLb77me5yAoyjBpY1EB8IFjygXP8_5dOgeCCql63y_k=.c061924e-46ac-49df-9df0-62cd5048aaaa@github.com>
References: <XLb77me5yAoyjBpY1EB8IFjygXP8_5dOgeCCql63y_k=.c061924e-46ac-49df-9df0-62cd5048aaaa@github.com>
Message-ID: <bL7jud4tnA6mLvzkXdO3hMl09zEPyehs9ZO6nT1yXtc=.8fb36031-a75b-4f2f-9cbd-99e3a674abe4@github.com>

> Normally when a virtual thread wrapper is used to run a test, the main thread is renamed to "old-m-a-i-n" and the new virtual thread that will act as the main thread is named "main". Neither is being done by `ProcessTools.main()`. This can cause problems for tests that expect the main thread that the test is running in to be called "main". It is instead left unnamed. This is causing the following 4 tests to fail:
> 
> com/sun/jdi/JdbMethodExitTest.java
> com/sun/jdi/JdbStepTest.java
> com/sun/jdi/JdbStopThreadTest.java
> com/sun/jdi/JdbStopThreadidTest.java
> 
> These tests also fail due to [JDK-8309397](https://bugs.openjdk.org/browse/JDK-8309397), which will be fixed after this CR, and also com/sun/jdi/JdbMethodExitTest.java fails due to [JDK-8309396](https://bugs.openjdk.org/browse/JDK-8309396), which will also subsequently be fixed.
> 
> Note this fix messed up one runtime test. It was expecting an exception message to mention the "main" thread rather than "old-m-a-i-n". Loosening the exception message matching pattern a bit solved the problem.
> 
> Testing was done by running all of tier1 and tier5.

Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:

 - No longer need reflection to call Thread.ofVirtual().unstarted()
 - Remove from problem list tests that are fixed by this PR.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14292/files
  - new: https://git.openjdk.org/jdk/pull/14292/files/de5ca147..9bcc200b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14292&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14292&range=01-02

  Stats: 17 lines in 2 files changed: 0 ins; 16 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14292.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14292/head:pull/14292

PR: https://git.openjdk.org/jdk/pull/14292

From sspitsyn at openjdk.org  Sat Jun  3 23:11:07 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 3 Jun 2023 23:11:07 GMT
Subject: RFR: 8309334: ProcessTools.main() does not properly set thread
 names when using the virtual thread wrapper [v3]
In-Reply-To: <bL7jud4tnA6mLvzkXdO3hMl09zEPyehs9ZO6nT1yXtc=.8fb36031-a75b-4f2f-9cbd-99e3a674abe4@github.com>
References: <XLb77me5yAoyjBpY1EB8IFjygXP8_5dOgeCCql63y_k=.c061924e-46ac-49df-9df0-62cd5048aaaa@github.com>
 <bL7jud4tnA6mLvzkXdO3hMl09zEPyehs9ZO6nT1yXtc=.8fb36031-a75b-4f2f-9cbd-99e3a674abe4@github.com>
Message-ID: <B4EO1Mrr9FLP-3JsAdR3QsGd_WkaE0s0YWo8EGEtXMk=.ec2ea60f-6acd-425d-8cb0-886c451946ba@github.com>

On Sat, 3 Jun 2023 21:34:16 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Normally when a virtual thread wrapper is used to run a test, the main thread is renamed to "old-m-a-i-n" and the new virtual thread that will act as the main thread is named "main". Neither is being done by `ProcessTools.main()`. This can cause problems for tests that expect the main thread that the test is running in to be called "main". It is instead left unnamed. This is causing the following 4 tests to fail:
>> 
>> com/sun/jdi/JdbMethodExitTest.java
>> com/sun/jdi/JdbStepTest.java
>> com/sun/jdi/JdbStopThreadTest.java
>> com/sun/jdi/JdbStopThreadidTest.java
>> 
>> These tests also fail due to [JDK-8309397](https://bugs.openjdk.org/browse/JDK-8309397), which will be fixed after this CR, and also com/sun/jdi/JdbMethodExitTest.java fails due to [JDK-8309396](https://bugs.openjdk.org/browse/JDK-8309396), which will also subsequently be fixed.
>> 
>> Note this fix messed up one runtime test. It was expecting an exception message to mention the "main" thread rather than "old-m-a-i-n". Loosening the exception message matching pattern a bit solved the problem.
>> 
>> Testing was done by running all of tier1 and tier5.
>
> Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - No longer need reflection to call Thread.ofVirtual().unstarted()
>  - Remove from problem list tests that are fixed by this PR.

Looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14292#pullrequestreview-1460389726

From alanb at openjdk.org  Sun Jun  4 07:18:08 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 4 Jun 2023 07:18:08 GMT
Subject: RFR: 8309334: ProcessTools.main() does not properly set thread
 names when using the virtual thread wrapper [v3]
In-Reply-To: <bL7jud4tnA6mLvzkXdO3hMl09zEPyehs9ZO6nT1yXtc=.8fb36031-a75b-4f2f-9cbd-99e3a674abe4@github.com>
References: <XLb77me5yAoyjBpY1EB8IFjygXP8_5dOgeCCql63y_k=.c061924e-46ac-49df-9df0-62cd5048aaaa@github.com>
 <bL7jud4tnA6mLvzkXdO3hMl09zEPyehs9ZO6nT1yXtc=.8fb36031-a75b-4f2f-9cbd-99e3a674abe4@github.com>
Message-ID: <5DZfskNZrZY5sENy22fgCrs6CAsoNo9GgnsM3gYVBdU=.dbbf65ec-dd7e-4afe-b80d-49151b23511e@github.com>

On Sat, 3 Jun 2023 21:34:16 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Normally when a virtual thread wrapper is used to run a test, the main thread is renamed to "old-m-a-i-n" and the new virtual thread that will act as the main thread is named "main". Neither is being done by `ProcessTools.main()`. This can cause problems for tests that expect the main thread that the test is running in to be called "main". It is instead left unnamed. This is causing the following 4 tests to fail:
>> 
>> com/sun/jdi/JdbMethodExitTest.java
>> com/sun/jdi/JdbStepTest.java
>> com/sun/jdi/JdbStopThreadTest.java
>> com/sun/jdi/JdbStopThreadidTest.java
>> 
>> These tests also fail due to [JDK-8309397](https://bugs.openjdk.org/browse/JDK-8309397), which will be fixed after this CR, and also com/sun/jdi/JdbMethodExitTest.java fails due to [JDK-8309396](https://bugs.openjdk.org/browse/JDK-8309396), which will also subsequently be fixed.
>> 
>> Note this fix messed up one runtime test. It was expecting an exception message to mention the "main" thread rather than "old-m-a-i-n". Loosening the exception message matching pattern a bit solved the problem.
>> 
>> Testing was done by running all of tier1 and tier5.
>
> Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - No longer need reflection to call Thread.ofVirtual().unstarted()
>  - Remove from problem list tests that are fixed by this PR.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14292#pullrequestreview-1460999128

From alanb at openjdk.org  Sun Jun  4 08:08:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 4 Jun 2023 08:08:04 GMT
Subject: RFR: 8307153: JVMTI GetThreadState on carrier should return
 STATE_WAITING
In-Reply-To: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>
References: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>
Message-ID: <SH2pr7y0t3C1v3EFDfgS4AArNAxNXbb1LTPC6xrKGI8=.2a629523-a681-4b61-988f-4df5e60e7a2b@github.com>

On Sat, 3 Jun 2023 10:53:04 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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

src/hotspot/share/prims/jvmtiEnvBase.cpp line 764:

> 762: 
> 763:   if (is_passive_carrier_thread(jt, thread_oop)) {
> 764:     state |= (JVMTI_THREAD_STATE_WAITING | JVMTI_THREAD_STATE_WAITING_INDEFINITELY);

This is testing 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.

One thing that is a bit confusing is the function name "is_passive_carrier_thread". A platform thread is either a carrier or not. Maybe for a different PR but I think is_passive_carrier_thread should be renamed to avoid the use of the word "passive".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14298#discussion_r1216368303

From sspitsyn at openjdk.org  Sun Jun  4 08:30:04 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sun, 4 Jun 2023 08:30:04 GMT
Subject: RFR: 8307153: JVMTI GetThreadState on carrier should return
 STATE_WAITING
In-Reply-To: <SH2pr7y0t3C1v3EFDfgS4AArNAxNXbb1LTPC6xrKGI8=.2a629523-a681-4b61-988f-4df5e60e7a2b@github.com>
References: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>
 <SH2pr7y0t3C1v3EFDfgS4AArNAxNXbb1LTPC6xrKGI8=.2a629523-a681-4b61-988f-4df5e60e7a2b@github.com>
Message-ID: <t-iQRZCgi0Jv6fpJDBRLID3Bhll-2ezYbVHfC7u79N0=.4db46ff4-351e-4737-81fb-b66ebb4358ed@github.com>

On Sun, 4 Jun 2023 08:05:34 GMT, Alan Bateman <alanb at openjdk.org> 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
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 764:
> 
>> 762: 
>> 763:   if (is_passive_carrier_thread(jt, thread_oop)) {
>> 764:     state |= (JVMTI_THREAD_STATE_WAITING | JVMTI_THREAD_STATE_WAITING_INDEFINITELY);
> 
> This is testing 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.
> 
> One thing that is a bit confusing is the function name "is_passive_carrier_thread". A platform thread is either a carrier or not. Maybe for a different PR but I think is_passive_carrier_thread should be renamed to avoid the use of the word "passive".

The lines 763-764 are to correct the state exactly for passive carrier thread, a carrier thread which can't progress until the execution control has not been returned from a virtual thread executed on the top. It is never for a platform thread which is not a carrier thread. "Passive" is the best word I was able to find for this meaning. Do you have any other word/suggestion in mind?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14298#discussion_r1216390108

From sspitsyn at openjdk.org  Sun Jun  4 09:38:51 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sun, 4 Jun 2023 09:38:51 GMT
Subject: RFR: 8304438: jcmd JVMTI.agent_load should obey
 EnableDynamicAgentLoading [v7]
In-Reply-To: <9H36lIpFiwG4v0oGPE2zCIawMJcNIhuGguz--qxjRnQ=.0fc08ed3-2d12-42d0-8b6c-3fa801d55427@github.com>
References: <9H36lIpFiwG4v0oGPE2zCIawMJcNIhuGguz--qxjRnQ=.0fc08ed3-2d12-42d0-8b6c-3fa801d55427@github.com>
Message-ID: <hZIjWAXkL46baHbbCp3IHLCvrHZEVolngk29ScegoaE=.b1210c08-0a09-4b76-8a51-84ac2c282994@github.com>

> The VM option EnableDynamicAgentLoading was added in JDK 9, default true, to allow deployment to choose whether to allow agents to be loaded/started in the VM. The VM option does the right thing for tools using the Attach API but jcmd JVMTI.agent_load was missed. This should be fixed to disallow loading JVMTI agents when the EnableDynamicAgentLoading is false.
> 
> The CSR is:
> [JDK-8309250](https://bugs.openjdk.org/browse/JDK-8309250): jcmd JVMTI.agent_load should obey EnableDynamicAgentLoading
> 
> Testing:
>  - run new test `test/jdk/sun/tools/jcmd/TestJcmdNoAgentLoad.java`
>  - TBD: submit mach5 tiers 1-5 to make sure no new regressions are introduced

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: add to TestJcmdNoAgentLoad default and enabled dynamic loading modes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14244/files
  - new: https://git.openjdk.org/jdk/pull/14244/files/18cad064..f82ce73e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14244&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14244&range=05-06

  Stats: 36 lines in 1 file changed: 31 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14244.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14244/head:pull/14244

PR: https://git.openjdk.org/jdk/pull/14244

From aph at openjdk.org  Sun Jun  4 10:20:23 2023
From: aph at openjdk.org (Andrew Haley)
Date: Sun, 4 Jun 2023 10:20:23 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v4]
In-Reply-To: <2sgbRGVCiStjmAspEqqpyWAM0IzbZfjFC6HHXlhbcyE=.9637c274-1b10-4103-b528-34719037362b@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <2sgbRGVCiStjmAspEqqpyWAM0IzbZfjFC6HHXlhbcyE=.9637c274-1b10-4103-b528-34719037362b@github.com>
Message-ID: <cG4YCrlfxg02tZVa_hgyAmYG7KtOE1JvxLvHvKMFZlg=.95772724-f962-4010-af11-1a38f97d8929@github.com>

On Fri, 2 Jun 2023 02:49:25 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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:
> 
>   Force PLAB sizes to align on card-table size

This patch  was submitted 2023-05-26, two week before RDP1. It is large and complex.

My biggest concern it that it doesn't seem to be well-isolated from the existing Shenandoah code. The biggest risk is that it breaks Trad (i.e. non-generational) Shenandoah. A patch like this takes a few weeks to review properly. I don't believe we should hurry the review process.

While this looks interesting, and it has promise for the future, it's not worth breaking anything for.

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

PR Comment: https://git.openjdk.org/jdk/pull/14185#issuecomment-1575504522

From alanb at openjdk.org  Sun Jun  4 11:17:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 4 Jun 2023 11:17:04 GMT
Subject: RFR: 8307153: JVMTI GetThreadState on carrier should return
 STATE_WAITING
In-Reply-To: <t-iQRZCgi0Jv6fpJDBRLID3Bhll-2ezYbVHfC7u79N0=.4db46ff4-351e-4737-81fb-b66ebb4358ed@github.com>
References: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>
 <SH2pr7y0t3C1v3EFDfgS4AArNAxNXbb1LTPC6xrKGI8=.2a629523-a681-4b61-988f-4df5e60e7a2b@github.com>
 <t-iQRZCgi0Jv6fpJDBRLID3Bhll-2ezYbVHfC7u79N0=.4db46ff4-351e-4737-81fb-b66ebb4358ed@github.com>
Message-ID: <MkJ9Qmy6wtW_uzB2VXyFbfMujlzTgF_Tc_DM6n0z9HU=.de134484-9fa3-4ac9-a68f-5a2b3b5be59c@github.com>

On Sun, 4 Jun 2023 08:26:06 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The lines 763-764 are to correct the state exactly for passive carrier thread, a carrier thread which can't progress until the execution control has not been returned from a virtual thread executed on the top. It is never for a platform thread which is not a carrier thread. "Passive" is the best word I was able to find for this meaning. Do you have any other word/suggestion in mind?

It's just a carrier. A platform thread becomes a carrier when a virtual thread is mounted, it ceases to be a carrier once the virtual thread is unmounted. The mental model is that the carrier is blocked so reporting its state as waiting indefinitely is correct. Maybe you don't want to rename it in this PR but renaming this function to something like is_carrying would convey that it's asking the question if a given JavaThread is carrying the given virtual thread oop.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14298#discussion_r1216568827

From alanb at openjdk.org  Sun Jun  4 11:40:13 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 4 Jun 2023 11:40:13 GMT
Subject: RFR: 8304438: jcmd JVMTI.agent_load should obey
 EnableDynamicAgentLoading [v7]
In-Reply-To: <hZIjWAXkL46baHbbCp3IHLCvrHZEVolngk29ScegoaE=.b1210c08-0a09-4b76-8a51-84ac2c282994@github.com>
References: <9H36lIpFiwG4v0oGPE2zCIawMJcNIhuGguz--qxjRnQ=.0fc08ed3-2d12-42d0-8b6c-3fa801d55427@github.com>
 <hZIjWAXkL46baHbbCp3IHLCvrHZEVolngk29ScegoaE=.b1210c08-0a09-4b76-8a51-84ac2c282994@github.com>
Message-ID: <sqoA83Kv6uTgidH2gs8f5tOiB4bXRvMzy_XnR4fEVnk=.4401eeb4-98b5-4912-bdd2-55bf885805d6@github.com>

On Sun, 4 Jun 2023 09:38:51 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The VM option EnableDynamicAgentLoading was added in JDK 9, default true, to allow deployment to choose whether to allow agents to be loaded/started in the VM. The VM option does the right thing for tools using the Attach API but jcmd JVMTI.agent_load was missed. This should be fixed to disallow loading JVMTI agents when the EnableDynamicAgentLoading is false.
>> 
>> The CSR is:
>> [JDK-8309250](https://bugs.openjdk.org/browse/JDK-8309250): jcmd JVMTI.agent_load should obey EnableDynamicAgentLoading
>> 
>> Testing:
>>  - run new test `test/jdk/sun/tools/jcmd/TestJcmdNoAgentLoad.java`
>>  - TBD: submit mach5 tiers 1-5 to make sure no new regressions are introduced
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: add to TestJcmdNoAgentLoad default and enabled dynamic loading modes

Implementation change looks fine. Once your branch is sync up to main line then it should mean EnableDynamicAgentLoading is only used in one function, so easy to understand.

test/jdk/sun/tools/jcmd/TestJcmdNoAgentLoad.java line 68:

> 66:     private static final String[] CMD = new String[] { "JVMTI.agent_load", "Agent.jar" };
> 67:     private static final String PTRN = "Dynamic agent loading is not enabled";
> 68:     private static boolean enableDynLoad = true;

It might be clear to change this to be a static final field name "dynamicLoadingEnabled", just suggesting "enabled" rather than "enable" as the usage in this test is to see if the option is enabled.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14244#pullrequestreview-1461132592
PR Review Comment: https://git.openjdk.org/jdk/pull/14244#discussion_r1216591017

From alanb at openjdk.org  Sun Jun  4 11:43:13 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 4 Jun 2023 11:43:13 GMT
Subject: RFR: 8309397: com/sun/jdi/JdbXXX tests fail due to not being run
 with -Djdk.trackAllThreads
In-Reply-To: <bqqUAEdMlqCx_2GepxPYY7pb-_-S-97hUdU6pbUK0wc=.17789771-2909-43f0-acbf-e933af44dcb5@github.com>
References: <Rjxov_l1m12SNVarRfEuGYlHKQPl-OC91q6MgtHpkqU=.c7ec0949-5c8c-4604-ac49-9012689a87a7@github.com>
 <zLljVXYvUWFxOBlrawDfp_wHOQMLhyXnk6dAvDBXW2w=.387c5460-2d1b-499b-88a3-9bfbcc2dabc6@github.com>
 <bqqUAEdMlqCx_2GepxPYY7pb-_-S-97hUdU6pbUK0wc=.17789771-2909-43f0-acbf-e933af44dcb5@github.com>
Message-ID: <uuH760tJIWVlhBubNKFNCdoeylafqVBgO76WUgTDZ4A=.8a34b89a-7bfe-49dc-a304-4781f0965d2f@github.com>

On Sat, 3 Jun 2023 18:57:55 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> So I think I should close this PR and update the [JDK-8309334](https://bugs.openjdk.org/browse/JDK-8309334) PR to remove the 3 tests that seem to pass with it and don't also need this PR to pass. The 4th test `com/sun/jdi/JdbMethodExitTest.java` needs an additional fix that I need to push separately.

Okay with me, thanks for confirming that jdk.trackAllThreads has no effect here.

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

PR Comment: https://git.openjdk.org/jdk/pull/14293#issuecomment-1575534183

From cjplummer at openjdk.org  Sun Jun  4 18:21:12 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sun, 4 Jun 2023 18:21:12 GMT
Subject: RFR: 8309334: ProcessTools.main() does not properly set thread
 names when using the virtual thread wrapper [v3]
In-Reply-To: <bL7jud4tnA6mLvzkXdO3hMl09zEPyehs9ZO6nT1yXtc=.8fb36031-a75b-4f2f-9cbd-99e3a674abe4@github.com>
References: <XLb77me5yAoyjBpY1EB8IFjygXP8_5dOgeCCql63y_k=.c061924e-46ac-49df-9df0-62cd5048aaaa@github.com>
 <bL7jud4tnA6mLvzkXdO3hMl09zEPyehs9ZO6nT1yXtc=.8fb36031-a75b-4f2f-9cbd-99e3a674abe4@github.com>
Message-ID: <eXfAbu8dKd2qW9i1T_z9ycm1K6Os6f_LECbBON_kOx0=.be5c426c-6753-4501-8de0-da271cfcb39a@github.com>

On Sat, 3 Jun 2023 21:34:16 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Normally when a virtual thread wrapper is used to run a test, the main thread is renamed to "old-m-a-i-n" and the new virtual thread that will act as the main thread is named "main". Neither is being done by `ProcessTools.main()`. This can cause problems for tests that expect the main thread that the test is running in to be called "main". It is instead left unnamed. This is causing the following 4 tests to fail:
>> 
>> com/sun/jdi/JdbMethodExitTest.java
>> com/sun/jdi/JdbStepTest.java
>> com/sun/jdi/JdbStopThreadTest.java
>> com/sun/jdi/JdbStopThreadidTest.java
>> 
>> These tests also fail due to [JDK-8309397](https://bugs.openjdk.org/browse/JDK-8309397), which will be fixed after this CR, and also com/sun/jdi/JdbMethodExitTest.java fails due to [JDK-8309396](https://bugs.openjdk.org/browse/JDK-8309396), which will also subsequently be fixed.
>> 
>> Note this fix messed up one runtime test. It was expecting an exception message to mention the "main" thread rather than "old-m-a-i-n". Loosening the exception message matching pattern a bit solved the problem.
>> 
>> Testing was done by running all of tier1 and tier5.
>
> Chris Plummer has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - No longer need reflection to call Thread.ofVirtual().unstarted()
>  - Remove from problem list tests that are fixed by this PR.

Thanks for the reviews Leonid, Alan, Serguei and Alex!

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

PR Comment: https://git.openjdk.org/jdk/pull/14292#issuecomment-1575663199

From cjplummer at openjdk.org  Sun Jun  4 18:21:14 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sun, 4 Jun 2023 18:21:14 GMT
Subject: Integrated: 8309334: ProcessTools.main() does not properly set thread
 names when using the virtual thread wrapper
In-Reply-To: <XLb77me5yAoyjBpY1EB8IFjygXP8_5dOgeCCql63y_k=.c061924e-46ac-49df-9df0-62cd5048aaaa@github.com>
References: <XLb77me5yAoyjBpY1EB8IFjygXP8_5dOgeCCql63y_k=.c061924e-46ac-49df-9df0-62cd5048aaaa@github.com>
Message-ID: <L0cpvE8qdv9994S5EQYqJwtxaAqSbMuM0j6lc-RNpKA=.f64235d7-d4fd-4533-96d7-4cf0a12aae39@github.com>

On Fri, 2 Jun 2023 21:30:46 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Normally when a virtual thread wrapper is used to run a test, the main thread is renamed to "old-m-a-i-n" and the new virtual thread that will act as the main thread is named "main". Neither is being done by `ProcessTools.main()`. This can cause problems for tests that expect the main thread that the test is running in to be called "main". It is instead left unnamed. This is causing the following 4 tests to fail:
> 
> com/sun/jdi/JdbMethodExitTest.java
> com/sun/jdi/JdbStepTest.java
> com/sun/jdi/JdbStopThreadTest.java
> com/sun/jdi/JdbStopThreadidTest.java
> 
> These tests also fail due to [JDK-8309397](https://bugs.openjdk.org/browse/JDK-8309397), which will be fixed after this CR, and also com/sun/jdi/JdbMethodExitTest.java fails due to [JDK-8309396](https://bugs.openjdk.org/browse/JDK-8309396), which will also subsequently be fixed.
> 
> Note this fix messed up one runtime test. It was expecting an exception message to mention the "main" thread rather than "old-m-a-i-n". Loosening the exception message matching pattern a bit solved the problem.
> 
> Testing was done by running all of tier1 and tier5.

This pull request has now been integrated.

Changeset: ecb17532
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ecb17532dc8f3e271ad2d6550127a2253569cf9b
Stats:     24 lines in 3 files changed: 5 ins; 16 del; 3 mod

8309334: ProcessTools.main() does not properly set thread names when using the virtual thread wrapper

Reviewed-by: amenkov, lmesnik, sspitsyn, alanb

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

PR: https://git.openjdk.org/jdk/pull/14292

From cjplummer at openjdk.org  Sun Jun  4 18:47:13 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sun, 4 Jun 2023 18:47:13 GMT
Subject: RFR: 8309396: com/sun/jdi/JdbMethodExitTest.java fails with
 virtual threads due to a bug in determining the main thread id [v2]
In-Reply-To: <_rWgi41CJ8newOTI2hqbjeNgOCCDTnNq030O6wXi_RI=.436a6404-306a-4001-b193-1206ee40f85d@github.com>
References: <_rWgi41CJ8newOTI2hqbjeNgOCCDTnNq030O6wXi_RI=.436a6404-306a-4001-b193-1206ee40f85d@github.com>
Message-ID: <eYT7Ufm_eWge731leRG6LHFg6iZeEMDZNOIkEVlw3ws=.5c0a0cc9-a9c3-42b0-a7fc-c21f24ef3433@github.com>

> JdbMethodExitTest.java tries to determine the jdb threadID for the "main" thread, and then later use it in jdb commands that require a threadID. It does this by first having the debuggee execute the following:
> 
> `        System.out.println("threadid="+Thread.currentThread().getId());`
> 
> And then later on the test parses the threadID from this output. The problem is that the id returned by getId() has no relation to threadIDs used by jdb, which are actually JDWP ObjectIDs. In the past this has worked due to some dumb luck. getID() always returns 1 for the main thread, which is always the thread we are executing in. Coincidentally the JDWP ObjectID for the main Thread object is also always 1 because this is the first ObjectID that the debug agent ever needs to create. However, when the debuggee main thread is a virtual thread, neither getId() nor JDWP assign 1 to the threadID, and in fact both will end up with very different values for the threadID. The end result is errors from jdb for using an invalid threadID.
> 
> The correct threadID can be obtained by executing the jdb "threads" command and parsing it from a line that looks like the following:
> 
> `   (java.lang.VirtualThread)694 main running (at breakpoint)`
> 
> Note this test will also fail due to [JDK-8309334](https://bugs.openjdk.org/browse/JDK-8309334), which should be fixed first. 
> 
> I've tested with mach5 tier5 in a workspace that has integrated the various CRs mentioned. Once JDK-8309334 is fixed, before integrating this PR I'll first merge and verify that the test being removed from the problem list by this PR also passes.

Chris Plummer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - fix minor merge issue
 - merge
 - remove test from problem list
 - properly determine the main threadId

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

Changes: https://git.openjdk.org/jdk/pull/14294/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14294&range=01
  Stats: 11 lines in 2 files changed: 5 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14294.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14294/head:pull/14294

PR: https://git.openjdk.org/jdk/pull/14294

From kdnilsen at openjdk.org  Sun Jun  4 21:39:58 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sun, 4 Jun 2023 21:39:58 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v5]
In-Reply-To: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
Message-ID: <fcRlEmBBI3U8CovyR6Sp0qt49jlim5s6SdXAlpAx_tM=.a3102b4e-decd-4068-9cb5-8fa6fe6708f8@github.com>

> 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 three asserts making comparisons between atomic volatile variables
  
  Though changes to the volatile variables are individually protected by
  Atomic load and store operations, these asserts were not assuring
  atomic access to multiple volatile variables, each of which could be
  modified independently of the others.  The asserts were therefore not
  trustworthy, as has been confirmed by more extensive testing.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14185/files
  - new: https://git.openjdk.org/jdk/pull/14185/files/d4d2f1cf..8d80780a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14185&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14185&range=03-04

  Stats: 18 lines in 2 files changed: 0 ins; 18 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

From cjplummer at openjdk.org  Mon Jun  5 04:11:28 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 5 Jun 2023 04:11:28 GMT
Subject: RFR: 8309420: con/sun/jdi/StepTest.java fails with virtual thread
 wrapper
Message-ID: <av9ig1PwtvEjkgBDkNizeyzkLb4IDuEgMbv9ABq8vhs=.fac3313d-291f-4c81-914d-a67d14916911@github.com>

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.

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

Commit messages:
 - Fix StepTest for virtual threads wrapper

Changes: https://git.openjdk.org/jdk/pull/14307/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14307&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309420
  Stats: 21 lines in 2 files changed: 10 ins; 4 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/14307.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14307/head:pull/14307

PR: https://git.openjdk.org/jdk/pull/14307

From alanb at openjdk.org  Mon Jun  5 06:19:27 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 5 Jun 2023 06:19:27 GMT
Subject: RFR: 8309408: Thread.sleep cleanup
Message-ID: <aQgYdV9yETAis_U44TCaI5C5MTR4DMMD-5Li28_cbvc=.6d65e000-4b13-4f27-a7d8-e6854e99337f@github.com>

Thread.sleep has had quite a bit of churn recently to support virtual threads, add sleep(Duration), a JFR event, and the change the underlying implementation to support sub-millis precision. I think the changes have settled down now so we can do some small cleanups that came up in PR discussions. The cleanups were kicked down the road as it requires tracking down faraway tests that depend on the stack depth and the names of internal methods. The two cleanups proposed here are:

1.  Add a private sleepNanos method that creates/commits the JFR event around the sleep, this avoids duplicate code in the 3 sleep methods.
2.  Rename JVM_Sleep to JVM_SleepNanos to make it clear that it takes the sleep time in nanoseconds, esp. when Thread.sleep's parameter is milliseconds.

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

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/14303/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14303&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309408
  Stats: 75 lines in 10 files changed: 27 ins; 32 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/14303.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14303/head:pull/14303

PR: https://git.openjdk.org/jdk/pull/14303

From dholmes at openjdk.org  Mon Jun  5 07:31:12 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 5 Jun 2023 07:31:12 GMT
Subject: RFR: 8309408: Thread.sleep cleanup
In-Reply-To: <aQgYdV9yETAis_U44TCaI5C5MTR4DMMD-5Li28_cbvc=.6d65e000-4b13-4f27-a7d8-e6854e99337f@github.com>
References: <aQgYdV9yETAis_U44TCaI5C5MTR4DMMD-5Li28_cbvc=.6d65e000-4b13-4f27-a7d8-e6854e99337f@github.com>
Message-ID: <s4RVxlZSY-yAzXf20pgbaAL1MHvqtj28REIM2j2cVbY=.0015b333-a3e6-4e84-920a-278a534ab279@github.com>

On Sun, 4 Jun 2023 11:28:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thread.sleep has had quite a bit of churn recently to support virtual threads, add sleep(Duration), a JFR event, and the change the underlying implementation to support sub-millis precision. I think the changes have settled down now so we can do some small cleanups that came up in PR discussions. The cleanups were kicked down the road as it requires tracking down faraway tests that depend on the stack depth and the names of internal methods. The two cleanups proposed here are:
> 
> 1.  Add a private sleepNanos method that creates/commits the JFR event around the sleep, this avoids duplicate code in the 3 sleep methods.
> 2.  Rename JVM_Sleep to JVM_SleepNanos to make it clear that it takes the sleep time in nanoseconds, esp. when Thread.sleep's parameter is milliseconds.

Looks good!

Keeping these tests up-to-date is painful, but as you note this is hopefully stabilized now.

There is one potential, pre-existing, test omission noted below.

Thanks.

test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/ThreadController.java line 660:

> 658:         expectedMethods.add(Thread.class.getName() + ".sleep");
> 659:         expectedMethods.add(Thread.class.getName() + ".sleepNanos");
> 660:         expectedMethods.add(Thread.class.getName() + ".sleepNanos0");

I'm surprised this test doesn't list `beforeSleep` and `afterSleep`.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14303#pullrequestreview-1461876843
PR Review Comment: https://git.openjdk.org/jdk/pull/14303#discussion_r1217641284

From stefank at openjdk.org  Mon Jun  5 08:23:05 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 5 Jun 2023 08:23:05 GMT
Subject: RFR: 8309408: Thread.sleep cleanup
In-Reply-To: <aQgYdV9yETAis_U44TCaI5C5MTR4DMMD-5Li28_cbvc=.6d65e000-4b13-4f27-a7d8-e6854e99337f@github.com>
References: <aQgYdV9yETAis_U44TCaI5C5MTR4DMMD-5Li28_cbvc=.6d65e000-4b13-4f27-a7d8-e6854e99337f@github.com>
Message-ID: <5QMR3WIYHEm2QUPqwMEb5fX_eHEYZv9qrv9BeJeeooI=.c53f6306-26cf-4d32-966a-c6f6795b760c@github.com>

On Sun, 4 Jun 2023 11:28:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thread.sleep has had quite a bit of churn recently to support virtual threads, add sleep(Duration), a JFR event, and the change the underlying implementation to support sub-millis precision. I think the changes have settled down now so we can do some small cleanups that came up in PR discussions. The cleanups were kicked down the road as it requires tracking down faraway tests that depend on the stack depth and the names of internal methods. The two cleanups proposed here are:
> 
> 1.  Add a private sleepNanos method that creates/commits the JFR event around the sleep, this avoids duplicate code in the 3 sleep methods.
> 2.  Rename JVM_Sleep to JVM_SleepNanos to make it clear that it takes the sleep time in nanoseconds, esp. when Thread.sleep's parameter is milliseconds.

I welcome this change. We were looking at this code on Friday and was thinking that it would have been good to rename sleep0 and JVM_Sleep. :)

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14303#pullrequestreview-1461982066

From kdnilsen at openjdk.org  Mon Jun  5 12:50:26 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 5 Jun 2023 12:50:26 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v5]
In-Reply-To: <fcRlEmBBI3U8CovyR6Sp0qt49jlim5s6SdXAlpAx_tM=.a3102b4e-decd-4068-9cb5-8fa6fe6708f8@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <fcRlEmBBI3U8CovyR6Sp0qt49jlim5s6SdXAlpAx_tM=.a3102b4e-decd-4068-9cb5-8fa6fe6708f8@github.com>
Message-ID: <Kqy3e45MLBywHwkxEFdDUxSwIQ4CzSvmnfoLoMXU4qg=.a77ea5c4-2c3f-40f9-80d0-d52466926e8a@github.com>

On Sun, 4 Jun 2023 21:39:58 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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 three asserts making comparisons between atomic volatile variables
>   
>   Though changes to the volatile variables are individually protected by
>   Atomic load and store operations, these asserts were not assuring
>   atomic access to multiple volatile variables, each of which could be
>   modified independently of the others.  The asserts were therefore not
>   trustworthy, as has been confirmed by more extensive testing.

src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 660:

> 658: void ShenandoahGeneration::increase_used(size_t bytes) {
> 659:   Atomic::add(&_used, bytes);
> 660: }

Note that C++ subexpression evaluation order is undefined.  Here is an example of what can go wrong with the removed assertion:

ThisThread:  fetches _affiliated_region_count * begins to multiply with region_size
OtherThread: increases _used and increases _affiliated_region_count appropriately (for a large allocation)
ThisThread: fetches _used and observes assert violation

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1218025633

From kdnilsen at openjdk.org  Mon Jun  5 13:06:25 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 5 Jun 2023 13:06:25 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v5]
In-Reply-To: <Kqy3e45MLBywHwkxEFdDUxSwIQ4CzSvmnfoLoMXU4qg=.a77ea5c4-2c3f-40f9-80d0-d52466926e8a@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <fcRlEmBBI3U8CovyR6Sp0qt49jlim5s6SdXAlpAx_tM=.a3102b4e-decd-4068-9cb5-8fa6fe6708f8@github.com>
 <Kqy3e45MLBywHwkxEFdDUxSwIQ4CzSvmnfoLoMXU4qg=.a77ea5c4-2c3f-40f9-80d0-d52466926e8a@github.com>
Message-ID: <z_YvveKPIiFsWmFpKeHGVxapGKPZdAR4BvAuV8O1yNg=.8468d920-0baf-4aad-9884-db5dade386f3@github.com>

On Mon, 5 Jun 2023 12:46:58 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove three asserts making comparisons between atomic volatile variables
>>   
>>   Though changes to the volatile variables are individually protected by
>>   Atomic load and store operations, these asserts were not assuring
>>   atomic access to multiple volatile variables, each of which could be
>>   modified independently of the others.  The asserts were therefore not
>>   trustworthy, as has been confirmed by more extensive testing.
>
> src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 660:
> 
>> 658: void ShenandoahGeneration::increase_used(size_t bytes) {
>> 659:   Atomic::add(&_used, bytes);
>> 660: }
> 
> Note that C++ subexpression evaluation order is undefined.  Here is an example of what can go wrong with the removed assertion:
> 
> ThisThread:  fetches _affiliated_region_count * begins to multiply with region_size
> OtherThread: increases _used and increases _affiliated_region_count appropriately (for a large allocation)
> ThisThread: fetches _used and observes assert violation

We have seen this race manifest in actual testing, which is what has motivated us to remove the assertions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1218045035

From kdnilsen at openjdk.org  Mon Jun  5 13:12:26 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 5 Jun 2023 13:12:26 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v5]
In-Reply-To: <fcRlEmBBI3U8CovyR6Sp0qt49jlim5s6SdXAlpAx_tM=.a3102b4e-decd-4068-9cb5-8fa6fe6708f8@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <fcRlEmBBI3U8CovyR6Sp0qt49jlim5s6SdXAlpAx_tM=.a3102b4e-decd-4068-9cb5-8fa6fe6708f8@github.com>
Message-ID: <J0d6HaPG9Ult5yv5boOZdRESDjC2x938zMEfT7gucRo=.a4163fb1-111b-4df4-a5c6-abd732438ec2@github.com>

On Sun, 4 Jun 2023 21:39:58 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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 three asserts making comparisons between atomic volatile variables
>   
>   Though changes to the volatile variables are individually protected by
>   Atomic load and store operations, these asserts were not assuring
>   atomic access to multiple volatile variables, each of which could be
>   modified independently of the others.  The asserts were therefore not
>   trustworthy, as has been confirmed by more extensive testing.

src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp line 85:

> 83: inline void ShenandoahHeapRegion::internal_increase_live_data(size_t s) {
> 84:   size_t new_live_data = Atomic::add(&_live_data, s, memory_order_relaxed);
> 85: #ifdef ASSERT

We have not observed violation of this assert during testing.  However, it appears unreliable in that _live_data increases monotonically under Atomic volatile math, whereas used() increases monotonically under heap lock, which we do not hold at the point of this assertion.

It is possible that another allocating thread increases both used() and _live_data.  We will see the increase in _live_data because _live_data changes are volatile Atomic.  However, we may not see the increase in used() because we did not acquire the heap lock and the value of _top() that contributes to calculation of used() is not volatile.  This situation can lead to an assertion failure.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1218051609

From goetz at openjdk.org  Mon Jun  5 15:04:07 2023
From: goetz at openjdk.org (Goetz Lindenmaier)
Date: Mon, 5 Jun 2023 15:04:07 GMT
Subject: RFR: JDK-8309225: Fix xlc17 clang 15 warnings in security and
 servicability
In-Reply-To: <TVjM9BfpfntsYda5nA4AcZazR-O8Mjl1SyTFu-Bmtpo=.d407a6a1-a865-49ea-8a58-deba1ba11d0c@github.com>
References: <TVjM9BfpfntsYda5nA4AcZazR-O8Mjl1SyTFu-Bmtpo=.d407a6a1-a865-49ea-8a58-deba1ba11d0c@github.com>
Message-ID: <wZt4TDgogWizg5BovML3V_BsV-w_NRvYdRx_6nfjDlY=.9c5ca724-5ab5-49db-9d26-86a6d808b916@github.com>

On Fri, 2 Jun 2023 10:19:53 GMT, JoKern65 <duke at openjdk.org> 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}

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/14282#issuecomment-1576966850

From goetz at openjdk.org  Mon Jun  5 15:08:08 2023
From: goetz at openjdk.org (Goetz Lindenmaier)
Date: Mon, 5 Jun 2023 15:08:08 GMT
Subject: RFR: JDK-8309225: Fix xlc17 clang 15 warnings in security and
 servicability
In-Reply-To: <TVjM9BfpfntsYda5nA4AcZazR-O8Mjl1SyTFu-Bmtpo=.d407a6a1-a865-49ea-8a58-deba1ba11d0c@github.com>
References: <TVjM9BfpfntsYda5nA4AcZazR-O8Mjl1SyTFu-Bmtpo=.d407a6a1-a865-49ea-8a58-deba1ba11d0c@github.com>
Message-ID: <VZsed-wtXH9dT_RNHzsv8WZ0qY-l0y9yyTiZc5gSGmU=.9bf04e83-eb1c-456e-a8fe-094ea8e11af3@github.com>

On Fri, 2 Jun 2023 10:19:53 GMT, JoKern65 <duke at openjdk.org> 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}

TARGET_OS_MAC:
I agree we should not fix this one occurance as long as the warning is disabled in gcc.

IN6ADDR_ANY_INIT
Cannot change the macro, it comes from a system header.

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

Marked as reviewed by goetz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14282#pullrequestreview-1462766607

From alanb at openjdk.org  Mon Jun  5 15:13:06 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 5 Jun 2023 15:13:06 GMT
Subject: RFR: 8309408: Thread.sleep cleanup
In-Reply-To: <s4RVxlZSY-yAzXf20pgbaAL1MHvqtj28REIM2j2cVbY=.0015b333-a3e6-4e84-920a-278a534ab279@github.com>
References: <aQgYdV9yETAis_U44TCaI5C5MTR4DMMD-5Li28_cbvc=.6d65e000-4b13-4f27-a7d8-e6854e99337f@github.com>
 <s4RVxlZSY-yAzXf20pgbaAL1MHvqtj28REIM2j2cVbY=.0015b333-a3e6-4e84-920a-278a534ab279@github.com>
Message-ID: <WKHpH37ZatpB7C-Cg-8UDD0M7OEwWukcwgj5udvrkVU=.ee704a1a-4824-4e1c-977b-c73530eda53b@github.com>

On Mon, 5 Jun 2023 07:26:57 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Thread.sleep has had quite a bit of churn recently to support virtual threads, add sleep(Duration), a JFR event, and the change the underlying implementation to support sub-millis precision. I think the changes have settled down now so we can do some small cleanups that came up in PR discussions. The cleanups were kicked down the road as it requires tracking down faraway tests that depend on the stack depth and the names of internal methods. The two cleanups proposed here are:
>> 
>> 1.  Add a private sleepNanos method that creates/commits the JFR event around the sleep, this avoids duplicate code in the 3 sleep methods.
>> 2.  Rename JVM_Sleep to JVM_SleepNanos to make it clear that it takes the sleep time in nanoseconds, esp. when Thread.sleep's parameter is milliseconds.
>
> test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/ThreadController.java line 660:
> 
>> 658:         expectedMethods.add(Thread.class.getName() + ".sleep");
>> 659:         expectedMethods.add(Thread.class.getName() + ".sleepNanos");
>> 660:         expectedMethods.add(Thread.class.getName() + ".sleepNanos0");
> 
> I'm surprised this test doesn't list `beforeSleep` and `afterSleep`.

> There is one potential, pre-existing, test omission noted below.
> I'm surprised this test doesn't list `beforeSleep` and `afterSleep`.

The monitoring/stress/thread tests will fail if they observe an unexpected method name in the stack trace. I don't think it can happen because the tests poll the thread state and for SleepingThread, it will sample the stack trace when the thread state is timed-wait. The beforeSleep/afterSleep methods won't in the stack trace when sleeping. It would be harmless to add them in that they aren't going to cause these tests to fail but might help with any further changes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14303#discussion_r1218215964

From alanb at openjdk.org  Mon Jun  5 15:54:33 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 5 Jun 2023 15:54:33 GMT
Subject: RFR: 8309406: Change jdk.trackAllThreads to default to true
Message-ID: <tfQb4yI5onJUGBuJgLgvR-QlcXHcA850Z267aQRa4i0=.c2acbff6-d109-4e80-b981-bad41109271e@github.com>

Virtual threads created directly with the Thread API are not included in the new thread dump by default. This was a source of confusion in JDK 19/20 when virtual threads were in preview. We have decided to switch the default so that all virtual threads are observable. Future work will reduce/remove the overhead of tracking threads in the root container. The change proposed here has no impact to virtual threads created with the virtual ThreadPerTaskExecutor or StructuredTaskScope.

With jdk.trackAllThreads defaulting to true then the need for SharedThreadContainer to count threads can go away, as does the need for RootContainer::threads to return virtual threads blocked on I/O.

Most of the changes are to the test HotSpotDiagnosticMXBean/DumpThreads.java as this is expanded to cover more cases, and specifically more cases with thread groupings that correspond to the ThreadPerTaskExecutor and thread pools.

Testing: Test1-5

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

Commit messages:
 - requires vm.continuations
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/14300/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14300&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309406
  Stats: 319 lines in 6 files changed: 183 ins; 81 del; 55 mod
  Patch: https://git.openjdk.org/jdk/pull/14300.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14300/head:pull/14300

PR: https://git.openjdk.org/jdk/pull/14300

From duke at openjdk.org  Mon Jun  5 16:22:28 2023
From: duke at openjdk.org (Christine Flood)
Date: Mon, 5 Jun 2023 16:22:28 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v4]
In-Reply-To: <2sgbRGVCiStjmAspEqqpyWAM0IzbZfjFC6HHXlhbcyE=.9637c274-1b10-4103-b528-34719037362b@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <2sgbRGVCiStjmAspEqqpyWAM0IzbZfjFC6HHXlhbcyE=.9637c274-1b10-4103-b528-34719037362b@github.com>
Message-ID: <YTzYeh7qoqy_-kQ_DSrT66ShysqKp5lAmcTMN9S7-PU=.19f0bebc-d4a5-4428-a5b8-d368db931604@github.com>

On Fri, 2 Jun 2023 02:49:25 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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:
> 
>   Force PLAB sizes to align on card-table size

There are some applications where generational collectors are effective, but there are some applications where they aren't, like LRU caches.  I would like to see the changes made to Shenandoah to make it generational cleanly isolated from traditional Shenandoah so that both options remain available to our customers moving forward.

It seems unlikely that such changes can be completed before the deadline for RDP1.

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

PR Comment: https://git.openjdk.org/jdk/pull/14185#issuecomment-1575572311

From shade at openjdk.org  Mon Jun  5 17:28:08 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 5 Jun 2023 17:28:08 GMT
Subject: RFR: 8309408: Thread.sleep cleanup
In-Reply-To: <aQgYdV9yETAis_U44TCaI5C5MTR4DMMD-5Li28_cbvc=.6d65e000-4b13-4f27-a7d8-e6854e99337f@github.com>
References: <aQgYdV9yETAis_U44TCaI5C5MTR4DMMD-5Li28_cbvc=.6d65e000-4b13-4f27-a7d8-e6854e99337f@github.com>
Message-ID: <Nu86at67VHbLwludO5_y6eZKQ6qPa4LtXQj15OKF0vo=.509fbe94-1573-4c26-90e1-b4dd7ce1b780@github.com>

On Sun, 4 Jun 2023 11:28:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thread.sleep has had quite a bit of churn recently to support virtual threads, add sleep(Duration), a JFR event, and the change the underlying implementation to support sub-millis precision. I think the changes have settled down now so we can do some small cleanups that came up in PR discussions. The cleanups were kicked down the road as it requires tracking down faraway tests that depend on the stack depth and the names of internal methods. The two cleanups proposed here are:
> 
> 1.  Add a private sleepNanos method that creates/commits the JFR event around the sleep, this avoids duplicate code in the 3 sleep methods.
> 2.  Rename JVM_Sleep to JVM_SleepNanos to make it clear that it takes the sleep time in nanoseconds, esp. when Thread.sleep's parameter is milliseconds.

I think we need to delay this until [JDK-8309361](https://bugs.openjdk.org/browse/JDK-8309361) is resolved, in case we would like to revert [JDK-8305092](https://bugs.openjdk.org/browse/JDK-8305092).

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

PR Review: https://git.openjdk.org/jdk/pull/14303#pullrequestreview-1463041304

From rpressler at openjdk.org  Mon Jun  5 17:53:06 2023
From: rpressler at openjdk.org (Ron Pressler)
Date: Mon, 5 Jun 2023 17:53:06 GMT
Subject: RFR: 8309406: Change jdk.trackAllThreads to default to true
In-Reply-To: <tfQb4yI5onJUGBuJgLgvR-QlcXHcA850Z267aQRa4i0=.c2acbff6-d109-4e80-b981-bad41109271e@github.com>
References: <tfQb4yI5onJUGBuJgLgvR-QlcXHcA850Z267aQRa4i0=.c2acbff6-d109-4e80-b981-bad41109271e@github.com>
Message-ID: <W7r5H__CuenNnsw0P3GPc2fuD698_Q1WCpzgMYuBuhg=.cae1893e-aaef-4a7a-a6af-98d45cdb238d@github.com>

On Sat, 3 Jun 2023 13:41:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Virtual threads created directly with the Thread API are not included in the new thread dump by default. This was a source of confusion in JDK 19/20 when virtual threads were in preview. We have decided to switch the default so that all virtual threads are observable. Future work will reduce/remove the overhead of tracking threads in the root container. The change proposed here has no impact to virtual threads created with the virtual ThreadPerTaskExecutor or StructuredTaskScope.
> 
> With jdk.trackAllThreads defaulting to true then the need for SharedThreadContainer to count threads can go away, as does the need for RootContainer::threads to return virtual threads blocked on I/O.
> 
> Most of the changes are to the test HotSpotDiagnosticMXBean/DumpThreads.java as this is expanded to cover more cases, and specifically more cases with thread groupings that correspond to the ThreadPerTaskExecutor and thread pools.
> 
> Testing: Test1-5

Marked as reviewed by rpressler (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/14300#pullrequestreview-1463085546

From mchung at openjdk.org  Mon Jun  5 18:17:47 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 5 Jun 2023 18:17:47 GMT
Subject: RFR: 8309406: Change jdk.trackAllThreads to default to true
In-Reply-To: <tfQb4yI5onJUGBuJgLgvR-QlcXHcA850Z267aQRa4i0=.c2acbff6-d109-4e80-b981-bad41109271e@github.com>
References: <tfQb4yI5onJUGBuJgLgvR-QlcXHcA850Z267aQRa4i0=.c2acbff6-d109-4e80-b981-bad41109271e@github.com>
Message-ID: <gnQE47jZSxN4bz35w2DjBn5aswReap-A6oV8AB6DX9U=.e7ad3721-539d-4ab2-9eec-c9d0c4b67fd0@github.com>

On Sat, 3 Jun 2023 13:41:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Virtual threads created directly with the Thread API are not included in the new thread dump by default. This was a source of confusion in JDK 19/20 when virtual threads were in preview. We have decided to switch the default so that all virtual threads are observable. Future work will reduce/remove the overhead of tracking threads in the root container. The change proposed here has no impact to virtual threads created with the virtual ThreadPerTaskExecutor or StructuredTaskScope.
> 
> With jdk.trackAllThreads defaulting to true then the need for SharedThreadContainer to count threads can go away, as does the need for RootContainer::threads to return virtual threads blocked on I/O.
> 
> Most of the changes are to the test HotSpotDiagnosticMXBean/DumpThreads.java as this is expanded to cover more cases, and specifically more cases with thread groupings that correspond to the ThreadPerTaskExecutor and thread pools.
> 
> Testing: Test1-5

Looks okay to me.

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

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14300#pullrequestreview-1463111013

From sspitsyn at openjdk.org  Mon Jun  5 18:43:04 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 5 Jun 2023 18:43:04 GMT
Subject: RFR: 8304438: jcmd JVMTI.agent_load should obey
 EnableDynamicAgentLoading [v8]
In-Reply-To: <9H36lIpFiwG4v0oGPE2zCIawMJcNIhuGguz--qxjRnQ=.0fc08ed3-2d12-42d0-8b6c-3fa801d55427@github.com>
References: <9H36lIpFiwG4v0oGPE2zCIawMJcNIhuGguz--qxjRnQ=.0fc08ed3-2d12-42d0-8b6c-3fa801d55427@github.com>
Message-ID: <7ZA346z0mMulmI2vNQOcPn43KGYEvxIWT5Va704TnJw=.1c168e3f-bac6-49da-b49c-a3753bd892e6@github.com>

> The VM option EnableDynamicAgentLoading was added in JDK 9, default true, to allow deployment to choose whether to allow agents to be loaded/started in the VM. The VM option does the right thing for tools using the Attach API but jcmd JVMTI.agent_load was missed. This should be fixed to disallow loading JVMTI agents when the EnableDynamicAgentLoading is false.
> 
> The CSR is:
> [JDK-8309250](https://bugs.openjdk.org/browse/JDK-8309250): jcmd JVMTI.agent_load should obey EnableDynamicAgentLoading
> 
> Testing:
>  - run new test `test/jdk/sun/tools/jcmd/TestJcmdNoAgentLoad.java`
>  - TBD: submit mach5 tiers 1-5 to make sure no new regressions are introduced

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: add real java agent to TestJcmdNoAgentLoad

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14244/files
  - new: https://git.openjdk.org/jdk/pull/14244/files/f82ce73e..cf12a0ba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14244&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14244&range=06-07

  Stats: 35 lines in 2 files changed: 27 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/14244.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14244/head:pull/14244

PR: https://git.openjdk.org/jdk/pull/14244

From sspitsyn at openjdk.org  Mon Jun  5 18:43:07 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 5 Jun 2023 18:43:07 GMT
Subject: RFR: 8304438: jcmd JVMTI.agent_load should obey
 EnableDynamicAgentLoading [v7]
In-Reply-To: <sqoA83Kv6uTgidH2gs8f5tOiB4bXRvMzy_XnR4fEVnk=.4401eeb4-98b5-4912-bdd2-55bf885805d6@github.com>
References: <9H36lIpFiwG4v0oGPE2zCIawMJcNIhuGguz--qxjRnQ=.0fc08ed3-2d12-42d0-8b6c-3fa801d55427@github.com>
 <hZIjWAXkL46baHbbCp3IHLCvrHZEVolngk29ScegoaE=.b1210c08-0a09-4b76-8a51-84ac2c282994@github.com>
 <sqoA83Kv6uTgidH2gs8f5tOiB4bXRvMzy_XnR4fEVnk=.4401eeb4-98b5-4912-bdd2-55bf885805d6@github.com>
Message-ID: <QNORPOzU4x_tXqbDoEi1lXJcqBxxhqpS6KO4ORq9J50=.9ac8b262-94fa-4ed4-a3ab-2fe161ba9ef4@github.com>

On Sun, 4 Jun 2023 11:36:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: add to TestJcmdNoAgentLoad default and enabled dynamic loading modes
>
> test/jdk/sun/tools/jcmd/TestJcmdNoAgentLoad.java line 68:
> 
>> 66:     private static final String[] CMD = new String[] { "JVMTI.agent_load", "Agent.jar" };
>> 67:     private static final String PTRN = "Dynamic agent loading is not enabled";
>> 68:     private static boolean enableDynLoad = true;
> 
> It might be clearer to change this to be a static final field name "dynamicLoadingEnabled", just suggesting "enabled" rather than "enable" as the usage in this test is to see if the option is enabled.

Good suggestion, thanks. Fixed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14244#discussion_r1218449527

From sspitsyn at openjdk.org  Mon Jun  5 18:44:37 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 5 Jun 2023 18:44:37 GMT
Subject: RFR: 8304438: jcmd JVMTI.agent_load should obey
 EnableDynamicAgentLoading [v6]
In-Reply-To: <taNZ0M7Z5NRo_t7C4-z07RSo3_w5iPYRWlZDb-ZGw7o=.4161f7cd-b7be-4f1c-b2aa-27e8ca797a45@github.com>
References: <9H36lIpFiwG4v0oGPE2zCIawMJcNIhuGguz--qxjRnQ=.0fc08ed3-2d12-42d0-8b6c-3fa801d55427@github.com>
 <rESCXP1ugGHILSvfIC1tURtbi3d90EEZr0rRuCE6RU0=.8acbcec4-f9f1-4584-b493-6d14edcbbffa@github.com>
 <aX9JIq-7SOo2Tyn1j-luKrSYrJgdkXy-1eML1DsP6rM=.5efbb9b8-9492-4560-a816-48d47afc0cd8@github.com>
 <taNZ0M7Z5NRo_t7C4-z07RSo3_w5iPYRWlZDb-ZGw7o=.4161f7cd-b7be-4f1c-b2aa-27e8ca797a45@github.com>
Message-ID: <I3bYXHricrPy1OIUg6pCO_Xlt4hC80b2q_FMYqylFVE=.c86d2ce7-ba1b-42af-b590-a339da193a28@github.com>

On Fri, 2 Jun 2023 19:27:28 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> test/jdk/sun/tools/jcmd/TestJcmdNoAgentLoad.java line 42:
>> 
>>> 40:  * @library /test/lib
>>> 41:  *
>>> 42:  * @run main/othervm -XX:-EnableDynamicAgentLoading TestJcmdNoAgentLoad
>> 
>> The test verifies only one scenario. I think we need to test 3 scenarios:
>> - -XX:-EnableDynamicAgentLoading
>> - -XX:+EnableDynamicAgentLoading
>> - default (no EnableDynamicAgentLoading arg)
>
> I didn't find tests for EnableDynamicAgentLoading for attach API too (to ensure this fix doesn't break it)

Good suggestions, thanks.
Added three modes: default, disabled and enabled.
Also, added a real java agent to check if it has been loaded.
The jcmd is using the dynamic attach to load the agents, so it has to be tested as well.
Alan recently added new tests for this as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14244#discussion_r1218453869

From sspitsyn at openjdk.org  Mon Jun  5 19:00:49 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 5 Jun 2023 19:00:49 GMT
Subject: RFR: 8307153: JVMTI GetThreadState on carrier should return
 STATE_WAITING [v2]
In-Reply-To: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>
References: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>
Message-ID: <5-_kURDcYKd5WYKi9B331c8h6okVmGfvjdy_xqi1UqU=.012c360b-1b57-4773-b64b-d727dbf4daeb@github.com>

> 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 three additional commits since the last revision:

 - 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/84d8825f..e60da02e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14298&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14298&range=00-01

  Stats: 10489 lines in 228 files changed: 8499 ins; 1035 del; 955 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

From sspitsyn at openjdk.org  Mon Jun  5 19:01:11 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 5 Jun 2023 19:01:11 GMT
Subject: RFR: 8304438: jcmd JVMTI.agent_load should obey
 EnableDynamicAgentLoading [v9]
In-Reply-To: <9H36lIpFiwG4v0oGPE2zCIawMJcNIhuGguz--qxjRnQ=.0fc08ed3-2d12-42d0-8b6c-3fa801d55427@github.com>
References: <9H36lIpFiwG4v0oGPE2zCIawMJcNIhuGguz--qxjRnQ=.0fc08ed3-2d12-42d0-8b6c-3fa801d55427@github.com>
Message-ID: <6Jkd1TVSYX3__pNjLCxkHFVmgXm2NtY8JENyaDFPLZA=.903329bb-b573-4af8-ba0f-ed2833684047@github.com>

> The VM option EnableDynamicAgentLoading was added in JDK 9, default true, to allow deployment to choose whether to allow agents to be loaded/started in the VM. The VM option does the right thing for tools using the Attach API but jcmd JVMTI.agent_load was missed. This should be fixed to disallow loading JVMTI agents when the EnableDynamicAgentLoading is false.
> 
> The CSR is:
> [JDK-8309250](https://bugs.openjdk.org/browse/JDK-8309250): jcmd JVMTI.agent_load should obey EnableDynamicAgentLoading
> 
> Testing:
>  - run new test `test/jdk/sun/tools/jcmd/TestJcmdNoAgentLoad.java`
>  - TBD: submit mach5 tiers 1-5 to make sure no new regressions are introduced

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 ten additional commits since the last revision:

 - Merge
 - review: add real java agent to TestJcmdNoAgentLoad
 - review: add to TestJcmdNoAgentLoad default and enabled dynamic loading modes
 - Merge
 - review: use output.shouldHaveExitValue(0) in the test
 - review: use output.shouldContain()
 - move check for EnableDynamicAgentLoading to invoke_Agent_OnAttach
 - minor renaming in new test TestJcmdNoAgentLoad.java
 - 8304438: jcmd JVMTI.agent_load should obey EnableDynamicAgentLoading

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14244/files
  - new: https://git.openjdk.org/jdk/pull/14244/files/cf12a0ba..ada88c6d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14244&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14244&range=07-08

  Stats: 10489 lines in 228 files changed: 8499 ins; 1035 del; 955 mod
  Patch: https://git.openjdk.org/jdk/pull/14244.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14244/head:pull/14244

PR: https://git.openjdk.org/jdk/pull/14244

From sspitsyn at openjdk.org  Mon Jun  5 19:10:40 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 5 Jun 2023 19:10:40 GMT
Subject: RFR: 8304438: jcmd JVMTI.agent_load should obey
 EnableDynamicAgentLoading [v10]
In-Reply-To: <9H36lIpFiwG4v0oGPE2zCIawMJcNIhuGguz--qxjRnQ=.0fc08ed3-2d12-42d0-8b6c-3fa801d55427@github.com>
References: <9H36lIpFiwG4v0oGPE2zCIawMJcNIhuGguz--qxjRnQ=.0fc08ed3-2d12-42d0-8b6c-3fa801d55427@github.com>
Message-ID: <UcJR4Cp5NNbKY4ZZY66mVs9Z2NkXiI8c5fEloSp-vh0=.8a338902-3150-4cdc-8506-fec9f517545f@github.com>

> The VM option EnableDynamicAgentLoading was added in JDK 9, default true, to allow deployment to choose whether to allow agents to be loaded/started in the VM. The VM option does the right thing for tools using the Attach API but jcmd JVMTI.agent_load was missed. This should be fixed to disallow loading JVMTI agents when the EnableDynamicAgentLoading is false.
> 
> The CSR is:
> [JDK-8309250](https://bugs.openjdk.org/browse/JDK-8309250): jcmd JVMTI.agent_load should obey EnableDynamicAgentLoading
> 
> Testing:
>  - run new test `test/jdk/sun/tools/jcmd/TestJcmdNoAgentLoad.java`
>  - TBD: submit mach5 tiers 1-5 to make sure no new regressions are introduced

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  fix a typo and minor cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14244/files
  - new: https://git.openjdk.org/jdk/pull/14244/files/ada88c6d..16bbf3ca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14244&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14244&range=08-09

  Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14244.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14244/head:pull/14244

PR: https://git.openjdk.org/jdk/pull/14244

From sspitsyn at openjdk.org  Mon Jun  5 19:13:30 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 5 Jun 2023 19:13:30 GMT
Subject: RFR: 8304438: jcmd JVMTI.agent_load should obey
 EnableDynamicAgentLoading [v11]
In-Reply-To: <9H36lIpFiwG4v0oGPE2zCIawMJcNIhuGguz--qxjRnQ=.0fc08ed3-2d12-42d0-8b6c-3fa801d55427@github.com>
References: <9H36lIpFiwG4v0oGPE2zCIawMJcNIhuGguz--qxjRnQ=.0fc08ed3-2d12-42d0-8b6c-3fa801d55427@github.com>
Message-ID: <lNhRlKrVwApE9gppn5EhaSNrLWYA9zaVO0JqEATjyK0=.8a6ffa68-c01f-474a-a267-0689b2ede1d2@github.com>

> The VM option EnableDynamicAgentLoading was added in JDK 9, default true, to allow deployment to choose whether to allow agents to be loaded/started in the VM. The VM option does the right thing for tools using the Attach API but jcmd JVMTI.agent_load was missed. This should be fixed to disallow loading JVMTI agents when the EnableDynamicAgentLoading is false.
> 
> The CSR is:
> [JDK-8309250](https://bugs.openjdk.org/browse/JDK-8309250): jcmd JVMTI.agent_load should obey EnableDynamicAgentLoading
> 
> Testing:
>  - run new test `test/jdk/sun/tools/jcmd/TestJcmdNoAgentLoad.java`
>  - TBD: submit mach5 tiers 1-5 to make sure no new regressions are introduced

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  removed an obsolete comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14244/files
  - new: https://git.openjdk.org/jdk/pull/14244/files/16bbf3ca..4e8fe970

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14244&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14244&range=09-10

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14244.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14244/head:pull/14244

PR: https://git.openjdk.org/jdk/pull/14244

From alanb at openjdk.org  Mon Jun  5 19:46:53 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 5 Jun 2023 19:46:53 GMT
Subject: RFR: 8309408: Thread.sleep cleanup
In-Reply-To: <Nu86at67VHbLwludO5_y6eZKQ6qPa4LtXQj15OKF0vo=.509fbe94-1573-4c26-90e1-b4dd7ce1b780@github.com>
References: <aQgYdV9yETAis_U44TCaI5C5MTR4DMMD-5Li28_cbvc=.6d65e000-4b13-4f27-a7d8-e6854e99337f@github.com>
 <Nu86at67VHbLwludO5_y6eZKQ6qPa4LtXQj15OKF0vo=.509fbe94-1573-4c26-90e1-b4dd7ce1b780@github.com>
Message-ID: <MYT2jZZfh3gpAf3ovevvUHF4b1UhCnZfHdrJ7bmuBxk=.d0671acf-8f9d-4913-903a-8f5dde98a981@github.com>

On Mon, 5 Jun 2023 17:25:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I think we need to delay this until [JDK-8309361](https://bugs.openjdk.org/browse/JDK-8309361) is resolved, in case we would like to revert [JDK-8305092](https://bugs.openjdk.org/browse/JDK-8305092).

Okay, I won't integrate this until we see what the issue is. That said, if the sub-mills support needs to be reverted then I think we should keep the interface as nanos on the bound between the VM and the libraries. The reason is that it's mostly nanos at the Java level now, meaning 2 out of the 3 sleep methods support sub-mills, and the virtual thread sleep and the JFR event are in nanos too.

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

PR Comment: https://git.openjdk.org/jdk/pull/14303#issuecomment-1577374410

From amenkov at openjdk.org  Mon Jun  5 19:59:56 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 5 Jun 2023 19:59:56 GMT
Subject: RFR: 8304438: jcmd JVMTI.agent_load should obey
 EnableDynamicAgentLoading [v11]
In-Reply-To: <lNhRlKrVwApE9gppn5EhaSNrLWYA9zaVO0JqEATjyK0=.8a6ffa68-c01f-474a-a267-0689b2ede1d2@github.com>
References: <9H36lIpFiwG4v0oGPE2zCIawMJcNIhuGguz--qxjRnQ=.0fc08ed3-2d12-42d0-8b6c-3fa801d55427@github.com>
 <lNhRlKrVwApE9gppn5EhaSNrLWYA9zaVO0JqEATjyK0=.8a6ffa68-c01f-474a-a267-0689b2ede1d2@github.com>
Message-ID: <XJqtf7L3tNiODd-Vqh7Wtv7BKk7XhjN_3gNVQJ3psvc=.995757fa-9d7b-42a1-a546-dd3d4504ade4@github.com>

On Mon, 5 Jun 2023 19:13:30 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The VM option EnableDynamicAgentLoading was added in JDK 9, default true, to allow deployment to choose whether to allow agents to be loaded/started in the VM. The VM option does the right thing for tools using the Attach API but jcmd JVMTI.agent_load was missed. This should be fixed to disallow loading JVMTI agents when the EnableDynamicAgentLoading is false.
>> 
>> The CSR is:
>> [JDK-8309250](https://bugs.openjdk.org/browse/JDK-8309250): jcmd JVMTI.agent_load should obey EnableDynamicAgentLoading
>> 
>> Testing:
>>  - run new test `test/jdk/sun/tools/jcmd/TestJcmdNoAgentLoad.java`
>>  - TBD: submit mach5 tiers 1-5 to make sure no new regressions are introduced
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed an obsolete comment

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14244#pullrequestreview-1463299507

From cjplummer at openjdk.org  Mon Jun  5 20:10:54 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 5 Jun 2023 20:10:54 GMT
Subject: RFR: 8309408: Thread.sleep cleanup
In-Reply-To: <WKHpH37ZatpB7C-Cg-8UDD0M7OEwWukcwgj5udvrkVU=.ee704a1a-4824-4e1c-977b-c73530eda53b@github.com>
References: <aQgYdV9yETAis_U44TCaI5C5MTR4DMMD-5Li28_cbvc=.6d65e000-4b13-4f27-a7d8-e6854e99337f@github.com>
 <s4RVxlZSY-yAzXf20pgbaAL1MHvqtj28REIM2j2cVbY=.0015b333-a3e6-4e84-920a-278a534ab279@github.com>
 <WKHpH37ZatpB7C-Cg-8UDD0M7OEwWukcwgj5udvrkVU=.ee704a1a-4824-4e1c-977b-c73530eda53b@github.com>
Message-ID: <kQ3W95PGzZJZlAETD5X1vZLJrr2D6MQaUGYuANKzPEU=.8f8e19b2-d2d4-462e-b05f-b608e69549b8@github.com>

On Mon, 5 Jun 2023 15:10:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/ThreadController.java line 660:
>> 
>>> 658:         expectedMethods.add(Thread.class.getName() + ".sleep");
>>> 659:         expectedMethods.add(Thread.class.getName() + ".sleepNanos");
>>> 660:         expectedMethods.add(Thread.class.getName() + ".sleepNanos0");
>> 
>> I'm surprised this test doesn't list `beforeSleep` and `afterSleep`.
>
>> There is one potential, pre-existing, test omission noted below.
>> I'm surprised this test doesn't list `beforeSleep` and `afterSleep`.
> 
> The monitoring/stress/thread tests will fail if they observe an unexpected method name in the stack trace. I don't think it can happen because the tests poll the thread state and for SleepingThread, it will sample the stack trace when the thread state is timed-wait. The beforeSleep/afterSleep methods won't in the stack trace when sleeping. It would be harmless to add them in that they aren't going to cause these tests to fail but might help with any further changes.

The following commit in loom heavily modified this file with a lot of added expected methods. There are other related tests with similar changes. I'm not so sure I understand the need for so many additions, and also why expectedLength is so out of sync with the number of added method. I don't believe this commit was reviewed individually, but was just part of the overall loom review when merge into jdk. Perhaps it should be revisited.

https://github.com/openjdk/loom/commit/26e66bc1a6a0dd735c8138a696809caba3e82b26

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14303#discussion_r1218539693

From kdnilsen at openjdk.org  Mon Jun  5 20:13:11 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 5 Jun 2023 20:13:11 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v5]
In-Reply-To: <fcRlEmBBI3U8CovyR6Sp0qt49jlim5s6SdXAlpAx_tM=.a3102b4e-decd-4068-9cb5-8fa6fe6708f8@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <fcRlEmBBI3U8CovyR6Sp0qt49jlim5s6SdXAlpAx_tM=.a3102b4e-decd-4068-9cb5-8fa6fe6708f8@github.com>
Message-ID: <t0zVr52ZNPwTuRyYpEApzABcxzsKqPOTVhte4uXnTxs=.9663c19a-a927-4dcd-912c-6e7d9092e71d@github.com>

On Sun, 4 Jun 2023 21:39:58 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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 three asserts making comparisons between atomic volatile variables
>   
>   Though changes to the volatile variables are individually protected by
>   Atomic load and store operations, these asserts were not assuring
>   atomic access to multiple volatile variables, each of which could be
>   modified independently of the others.  The asserts were therefore not
>   trustworthy, as has been confirmed by more extensive testing.

src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp line 733:

> 731:     } else {
> 732:       iu_barrier(masm, val, tmp3);
> 733:       // TODO: store_check missing in upstream

Remove this comment with integration.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1218543687

From cjplummer at openjdk.org  Mon Jun  5 20:33:52 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 5 Jun 2023 20:33:52 GMT
Subject: RFR: 8307153: JVMTI GetThreadState on carrier should return
 STATE_WAITING [v2]
In-Reply-To: <5-_kURDcYKd5WYKi9B331c8h6okVmGfvjdy_xqi1UqU=.012c360b-1b57-4773-b64b-d727dbf4daeb@github.com>
References: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>
 <5-_kURDcYKd5WYKi9B331c8h6okVmGfvjdy_xqi1UqU=.012c360b-1b57-4773-b64b-d727dbf4daeb@github.com>
Message-ID: <w9eNJ5cyd7LsBC9fZOzKMnl4MaTbR3hqDGYTGVzXC5U=.2cd70811-9a5f-42a4-b065-851b426f3367@github.com>

On Mon, 5 Jun 2023 19:00:49 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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 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 three additional commits since the last revision:
> 
>  - Merge
>  - minor tweaks in libThreadStateTest.cpp
>  - 8307153: JVMTI GetThreadState on carrier should return STATE_WAITING

Without the fix in place, do your new tests reproduce the issue>

I'm trying to recall the origins of the filing of this CR. I thought I had noticed this issue while working with a JDI test and discussed it with you and Alan. Just wondering if there is something that can be done to a JDI test to also test for this.

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

PR Comment: https://git.openjdk.org/jdk/pull/14298#issuecomment-1577432927

From cjplummer at openjdk.org  Mon Jun  5 20:36:55 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 5 Jun 2023 20:36:55 GMT
Subject: RFR: 8304438: jcmd JVMTI.agent_load should obey
 EnableDynamicAgentLoading [v11]
In-Reply-To: <lNhRlKrVwApE9gppn5EhaSNrLWYA9zaVO0JqEATjyK0=.8a6ffa68-c01f-474a-a267-0689b2ede1d2@github.com>
References: <9H36lIpFiwG4v0oGPE2zCIawMJcNIhuGguz--qxjRnQ=.0fc08ed3-2d12-42d0-8b6c-3fa801d55427@github.com>
 <lNhRlKrVwApE9gppn5EhaSNrLWYA9zaVO0JqEATjyK0=.8a6ffa68-c01f-474a-a267-0689b2ede1d2@github.com>
Message-ID: <TyCAQN28Qm4inCBy4ooZoFNg2GnpcMSw2tZXZ83FSVI=.8a77c1d2-e682-4cf0-ae37-272bb632cdec@github.com>

On Mon, 5 Jun 2023 19:13:30 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The VM option EnableDynamicAgentLoading was added in JDK 9, default true, to allow deployment to choose whether to allow agents to be loaded/started in the VM. The VM option does the right thing for tools using the Attach API but jcmd JVMTI.agent_load was missed. This should be fixed to disallow loading JVMTI agents when the EnableDynamicAgentLoading is false.
>> 
>> The CSR is:
>> [JDK-8309250](https://bugs.openjdk.org/browse/JDK-8309250): jcmd JVMTI.agent_load should obey EnableDynamicAgentLoading
>> 
>> Testing:
>>  - run new test `test/jdk/sun/tools/jcmd/TestJcmdNoAgentLoad.java`
>>  - TBD: submit mach5 tiers 1-5 to make sure no new regressions are introduced
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed an obsolete comment

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14244#pullrequestreview-1463368797

From sspitsyn at openjdk.org  Mon Jun  5 21:08:57 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 5 Jun 2023 21:08:57 GMT
Subject: RFR: 8307153: JVMTI GetThreadState on carrier should return
 STATE_WAITING [v2]
In-Reply-To: <5-_kURDcYKd5WYKi9B331c8h6okVmGfvjdy_xqi1UqU=.012c360b-1b57-4773-b64b-d727dbf4daeb@github.com>
References: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>
 <5-_kURDcYKd5WYKi9B331c8h6okVmGfvjdy_xqi1UqU=.012c360b-1b57-4773-b64b-d727dbf4daeb@github.com>
Message-ID: <eK_F6S-wEFLXS2U9cBW1gn-KD9EvqWf2TqHc-FvKbGE=.30c9aab0-eb44-4c7d-a013-98163180c945@github.com>

On Mon, 5 Jun 2023 19:00:49 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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 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 three additional commits since the last revision:
> 
>  - Merge
>  - minor tweaks in libThreadStateTest.cpp
>  - 8307153: JVMTI GetThreadState on carrier should return STATE_WAITING

>

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

PR Comment: https://git.openjdk.org/jdk/pull/14298#issuecomment-1577475470

From sspitsyn at openjdk.org  Mon Jun  5 21:29:54 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 5 Jun 2023 21:29:54 GMT
Subject: RFR: 8307153: JVMTI GetThreadState on carrier should return
 STATE_WAITING [v2]
In-Reply-To: <MkJ9Qmy6wtW_uzB2VXyFbfMujlzTgF_Tc_DM6n0z9HU=.de134484-9fa3-4ac9-a68f-5a2b3b5be59c@github.com>
References: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>
 <SH2pr7y0t3C1v3EFDfgS4AArNAxNXbb1LTPC6xrKGI8=.2a629523-a681-4b61-988f-4df5e60e7a2b@github.com>
 <t-iQRZCgi0Jv6fpJDBRLID3Bhll-2ezYbVHfC7u79N0=.4db46ff4-351e-4737-81fb-b66ebb4358ed@github.com>
 <MkJ9Qmy6wtW_uzB2VXyFbfMujlzTgF_Tc_DM6n0z9HU=.de134484-9fa3-4ac9-a68f-5a2b3b5be59c@github.com>
Message-ID: <chf9KOskdhm96pUVVgA9gIS2aPHPTnHQ3cAAjDRYJV4=.331b1bdd-3dc5-4f4a-ba15-9514f8b39ee6@github.com>

On Sun, 4 Jun 2023 11:14:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The lines 763-764 are to correct the state exactly for passive carrier thread, a carrier thread which can't progress until the execution control has not been returned from a virtual thread executed on the top. It is never for a platform thread which is not a carrier thread. "Passive" is the best word I was able to find for this meaning. Do you have any other word/suggestion in mind?
>
>> The lines 763-764 are to correct the state exactly for passive carrier thread, a carrier thread which can't progress until the execution control has not been returned from a virtual thread executed on the top. It is never for a platform thread which is not a carrier thread. "Passive" is the best word I was able to find for this meaning. Do you have any other word/suggestion in mind?
> 
> It's just a carrier. A platform thread becomes a carrier when a virtual thread is mounted, it ceases to be a carrier once the virtual thread is unmounted. The mental model is that the carrier is blocked so reporting its state as waiting indefinitely is correct. Maybe you don't want to rename it in this PR but renaming this function to something like is_carrying would convey that it's asking the question if a given JavaThread is carrying the given virtual thread oop.

Okay, I see you point. Unfortunately, I've always referred the platform thread with an executed FJP schedular as a carrier thread. The term 'carrier' with this meaning is everywhere in the JVMTI code. It looks very confusing to call a thread to be a carrier thread only during some phases of its execution.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14298#discussion_r1218613536

From cjplummer at openjdk.org  Mon Jun  5 21:43:52 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 5 Jun 2023 21:43:52 GMT
Subject: RFR: 8309406: Change jdk.trackAllThreads to default to true
In-Reply-To: <tfQb4yI5onJUGBuJgLgvR-QlcXHcA850Z267aQRa4i0=.c2acbff6-d109-4e80-b981-bad41109271e@github.com>
References: <tfQb4yI5onJUGBuJgLgvR-QlcXHcA850Z267aQRa4i0=.c2acbff6-d109-4e80-b981-bad41109271e@github.com>
Message-ID: <ahzouAOQ0KT-FqJQ4_VLkiXj4LgrzKWsk3nQF0myFuA=.4ce96478-cc74-4f8d-8356-af454842e78d@github.com>

On Sat, 3 Jun 2023 13:41:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Virtual threads created directly with the Thread API are not included in the new thread dump by default. This was a source of confusion in JDK 19/20 when virtual threads were in preview. We have decided to switch the default so that all virtual threads are observable. Future work will reduce/remove the overhead of tracking threads in the root container. The change proposed here has no impact to virtual threads created with the virtual ThreadPerTaskExecutor or StructuredTaskScope.
> 
> With jdk.trackAllThreads defaulting to true then the need for SharedThreadContainer to count threads can go away, as does the need for RootContainer::threads to return virtual threads blocked on I/O.
> 
> Most of the changes are to the test HotSpotDiagnosticMXBean/DumpThreads.java as this is expanded to cover more cases, and specifically more cases with thread groupings that correspond to the ThreadPerTaskExecutor and thread pools.
> 
> Testing: Test1-5

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14300#pullrequestreview-1463531717

From cjplummer at openjdk.org  Mon Jun  5 22:02:01 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 5 Jun 2023 22:02:01 GMT
Subject: RFR: 8309505: com/sun/jdi/MethodEntryExitEvents.java due to finding
 wrong main thread
Message-ID: <5zpDBAYAdkyhhkEzww1cgfUqHLhb7BFbd1fosEydwoQ=.4d263e58-ef38-4430-8ff0-722dec02c722@github.com>

The test fails because it tries to determine the main debuggee thread by allowing it run until the debuggee class is loaded (it waits for the ClassPrepareEvent). Normally this would be done on the main debuggee thread. However, when using virtual threads, the main thread has yet to spawn the virtual thread to run the test on. The test is fixed by instead just waiting until the debuggee main method is entered.

Tested by running the test locally with and without the virtual test thread wrapper, and also all of tier1 plus tier5 svc tests.

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

Commit messages:
 - Fix virtual thread testing issue by waiting until debuggee main method is entered before gleaning the main thread.

Changes: https://git.openjdk.org/jdk/pull/14322/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14322&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309505
  Stats: 7 lines in 2 files changed: 1 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14322.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14322/head:pull/14322

PR: https://git.openjdk.org/jdk/pull/14322

From cjplummer at openjdk.org  Mon Jun  5 22:20:56 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 5 Jun 2023 22:20:56 GMT
Subject: RFR: 8309506: com/sun/jdi/MultiBreakpointsTest.java fails with virtual
 test thread factory
Message-ID: <IwS2fAmNudmDi-7xVY8AhB1OY1ad6jWBKZFNCBiN-VY=.685d6b39-fc0d-467b-bcf1-b758bd6ad02e@github.com>

The test fails when the main debuggee thread is a virtual thread, because virtual threads are always daemon threads. Because of this all the test threads that the debuggee creates are also daemon threads. The main deuggee thread immediately exits after creating the test threads, and at that point there are no non-daemon threads left running to keep the debuggee process alive, so the test threads never get a chance to do all the work that is expected of them. 

The fix is to use Thread.join() to prevent the main test thread from exiting until all the created tests threads have exited. I also updated the test so when run using the virtual test thread factory, the debuggee test threads will now be virtual threads. Previously just the main debuggee thread would be a virtual thread. This is not a bug fix, but does provide better virtual thread testing.

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

Commit messages:
 - Fix virtual thread issues by using join(). Also make test threads be virtual theads when the main debuggee thread is a virtual thread.

Changes: https://git.openjdk.org/jdk/pull/14323/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14323&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309506
  Stats: 16 lines in 2 files changed: 10 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14323.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14323/head:pull/14323

PR: https://git.openjdk.org/jdk/pull/14323

From amenkov at openjdk.org  Mon Jun  5 23:46:53 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 5 Jun 2023 23:46:53 GMT
Subject: RFR: JDK-8306441: Enhance parallel heap dump [v6]
In-Reply-To: <4O3fdBsNuvwrymizPAQ1aXDMBVkHo9n841Ez5NqgY98=.28c881c8-2ae0-4736-bb25-7422ff9f60a3@github.com>
References: <8YqPPHSW4K1s0t317Kp6UqvoGuv5v9oCbjtQ9FX8p2o=.0f6c687b-d031-401d-901d-1ec532715cdc@github.com>
 <4O3fdBsNuvwrymizPAQ1aXDMBVkHo9n841Ez5NqgY98=.28c881c8-2ae0-4736-bb25-7422ff9f60a3@github.com>
Message-ID: <R5V84tAKKFgRBbieFdut8fSow6iyKQGSeLjbS4c6ReM=.2d788130-4503-4377-b865-83091227c19e@github.com>

On Wed, 17 May 2023 09:23:17 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> ### Motivation and proposal
>> Hi, heap dump brings about pauses for application's execution(STW), this is a well-known pain. JDK-8252842 have added parallel support to heapdump in an attempt to alleviate this issue. However, all concurrent threads competitively write heap data to the same file, and more memory is required to maintain the concurrent buffer queue. In experiments, we did not feel a significant performance improvement from that.
>> 
>> The minor-pause solution, which is presented in this PR, is a two-stage segmented heap dump:
>> 
>> 1. Stage One(STW): Concurrent threads directly write data to multiple heap files.
>> 2. Stage Two(Non-STW): Merge multiple heap files into one complete heap dump file.
>> 
>> Now concurrent worker threads are not required to maintain a buffer queue, which would result in more memory overhead, nor do they need to compete for locks.
>> 
>> ### Performance evaluation
>> | memory | numOfThread | STW         | Total      | Compression |
>> | --- | --------- | -------------- | ------------ | -------- |
>> | 8g | 1 thread | 15.612 secs | 15.612 secs | N |
>> | 8g | 32 thread |  2.5617250 secs | 14.498 secs | N |
>> | 8g | 32 thread | 2.3084878 secs | 3.198 secs | Compress1 |
>> | 8g | 32 thread | 10.9355128 secs | 21.882 secs | Compress2 |
>> | 8g | 96 thread | 2.6790452 secs | 14.012 secs | N |
>> | 8g | 96 thread | 2.3044796 secs | 3.589 secs | Compress1 |
>> | 8g | 96 thread | 9.7585151 secs | 20.219 secs| Compress2 |
>> | 16g | 1 thread | 26.278 secs | 26.278 secs | N |
>> | 16g | 32 thread |  5.2313740 secs | 26.417 secs | N |
>> | 16g | 32 thread | 5.6946983 secs | 6.538 secs | Compress1 |
>> | 16g | 32 thread | 21.8211105 secs | 41.133 secs | Compress2 |
>> | 16g | 96 thread | 6.2445556 secs | 27.141 secs | N |
>> | 16g | 96 thread | 4.6007096 secs | 6.259 secs | Compress1 |
>> | 16g | 96 thread | 19.2965783 secs |  39.007 secs | Compress2 |
>> | 32g | 1 thread | 48.149 secs | 48.149 secs | N |
>> | 32g | 32 thread | 10.7734677 secs | 61.643 secs | N |
>> | 32g | 32 thread | 10.1642097 secs | 10.903 secs | Compress1 |
>> | 32g | 32 thread | 43.8407607 secs | 88.152 secs | Compress2 |
>> | 32g | 96 thread | 13.1522042 secs | 61.432 secs | N |
>> | 32g | 96 thread | 9.0954641 secs | 9.885 secs | Compress1 |
>> | 32g | 96 thread | 38.9900931 secs | 80.574 secs | Compress2 |
>> | 64g | 1 thread |  100.583 secs | 100.583 secs | N |
>> | 64g | 32 thread | 20.9233744 secs | 134.701 secs | N |
>> | 64g | 32 thread | 18.5023784 secs | 19.358 secs | Compre...
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename back to heapdumpCompression

A lot of code movement is caused by moving AbstractDumpWriter class from heapDumper.cpp to heapDumpCompression.hpp/cpp
I'm not happy with huge heapDumper.cpp file, but this refactoring does not look good to me.
Currently all logic about hprof file structure is in heapDumper.cpp, it's not visible outside.
With your fix the logic is spread in heapDumper.hpp/.cpp and heapDumpCompression.hpp/cpp

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

PR Comment: https://git.openjdk.org/jdk/pull/13667#issuecomment-1577693210

From kdnilsen at openjdk.org  Mon Jun  5 23:57:09 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 5 Jun 2023 23:57:09 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v5]
In-Reply-To: <fcRlEmBBI3U8CovyR6Sp0qt49jlim5s6SdXAlpAx_tM=.a3102b4e-decd-4068-9cb5-8fa6fe6708f8@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <fcRlEmBBI3U8CovyR6Sp0qt49jlim5s6SdXAlpAx_tM=.a3102b4e-decd-4068-9cb5-8fa6fe6708f8@github.com>
Message-ID: <58eIIR00lhW278uv5z9Klo0SBJJWfn6D4JQFqgslqdE=.ca795de6-2480-4bb4-bbdc-12388f8fe388@github.com>

On Sun, 4 Jun 2023 21:39:58 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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 three asserts making comparisons between atomic volatile variables
>   
>   Though changes to the volatile variables are individually protected by
>   Atomic load and store operations, these asserts were not assuring
>   atomic access to multiple volatile variables, each of which could be
>   modified independently of the others.  The asserts were therefore not
>   trustworthy, as has been confirmed by more extensive testing.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahPassiveHeuristics.cpp 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.

Copyright overreach.   Revert.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1218719643

From sspitsyn at openjdk.org  Tue Jun  6 00:03:03 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 Jun 2023 00:03:03 GMT
Subject: Integrated: 8304438: jcmd JVMTI.agent_load should obey
 EnableDynamicAgentLoading
In-Reply-To: <9H36lIpFiwG4v0oGPE2zCIawMJcNIhuGguz--qxjRnQ=.0fc08ed3-2d12-42d0-8b6c-3fa801d55427@github.com>
References: <9H36lIpFiwG4v0oGPE2zCIawMJcNIhuGguz--qxjRnQ=.0fc08ed3-2d12-42d0-8b6c-3fa801d55427@github.com>
Message-ID: <mAMqyvTQOHztsUeIuGTqOrKOxMUTAYUqF5CsW-YJmfM=.9e5078f0-8a15-4439-855c-68b40b271943@github.com>

On Wed, 31 May 2023 10:08:46 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The VM option EnableDynamicAgentLoading was added in JDK 9, default true, to allow deployment to choose whether to allow agents to be loaded/started in the VM. The VM option does the right thing for tools using the Attach API but jcmd JVMTI.agent_load was missed. This should be fixed to disallow loading JVMTI agents when the EnableDynamicAgentLoading is false.
> 
> The CSR is:
> [JDK-8309250](https://bugs.openjdk.org/browse/JDK-8309250): jcmd JVMTI.agent_load should obey EnableDynamicAgentLoading
> 
> Testing:
>  - run new test `test/jdk/sun/tools/jcmd/TestJcmdNoAgentLoad.java`
>  - TBD: submit mach5 tiers 1-5 to make sure no new regressions are introduced

This pull request has now been integrated.

Changeset: 4b153498
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4b1534989b39139aaa2952564e2b4098181a9eee
Stats:     124 lines in 4 files changed: 117 ins; 4 del; 3 mod

8304438: jcmd JVMTI.agent_load should obey EnableDynamicAgentLoading

Reviewed-by: cjplummer, alanb, amenkov

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

PR: https://git.openjdk.org/jdk/pull/14244

From cjplummer at openjdk.org  Tue Jun  6 00:09:53 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 6 Jun 2023 00:09:53 GMT
Subject: RFR: 8309509: com/sun/jdi/RedefineNestmateAttr/TestNestmateAttr.java
 fails with virtual test thread factory
Message-ID: <oqLBwARuJ3rFGRCxCEdnVbvNyLP1DxCHHixj5OYEJ3Y=.462f7350-24f7-4e41-9db5-8288f6c26b6d@github.com>

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.

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

Commit messages:
 - Make sure we always run debug agent with includevirtualthreads=y

Changes: https://git.openjdk.org/jdk/pull/14324/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14324&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309509
  Stats: 7 lines in 2 files changed: 3 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14324.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14324/head:pull/14324

PR: https://git.openjdk.org/jdk/pull/14324

From amenkov at openjdk.org  Tue Jun  6 00:12:52 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 6 Jun 2023 00:12:52 GMT
Subject: RFR: 8309505: com/sun/jdi/MethodEntryExitEvents.java due to
 finding wrong main thread
In-Reply-To: <5zpDBAYAdkyhhkEzww1cgfUqHLhb7BFbd1fosEydwoQ=.4d263e58-ef38-4430-8ff0-722dec02c722@github.com>
References: <5zpDBAYAdkyhhkEzww1cgfUqHLhb7BFbd1fosEydwoQ=.4d263e58-ef38-4430-8ff0-722dec02c722@github.com>
Message-ID: <jHs3a199qLHdv4r_iEdMv_fbr9NXUPpzA9413MMegQM=.4cd2658e-cd4c-471b-8c6b-aa255c56e644@github.com>

On Mon, 5 Jun 2023 21:55:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The test fails because it tries to determine the main debuggee thread by allowing it run until the debuggee class is loaded (it waits for the ClassPrepareEvent). Normally this would be done on the main debuggee thread. However, when using virtual threads, the main thread has yet to spawn the virtual thread to run the test on. The test is fixed by instead just waiting until the debuggee main method is entered.
> 
> Tested by running the test locally with and without the virtual test thread wrapper, and also all of tier1 plus tier5 svc tests.

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14322#pullrequestreview-1463861905

From sspitsyn at openjdk.org  Tue Jun  6 00:15:04 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 Jun 2023 00:15:04 GMT
Subject: RFR: 8304438: jcmd JVMTI.agent_load should obey
 EnableDynamicAgentLoading [v11]
In-Reply-To: <lNhRlKrVwApE9gppn5EhaSNrLWYA9zaVO0JqEATjyK0=.8a6ffa68-c01f-474a-a267-0689b2ede1d2@github.com>
References: <9H36lIpFiwG4v0oGPE2zCIawMJcNIhuGguz--qxjRnQ=.0fc08ed3-2d12-42d0-8b6c-3fa801d55427@github.com>
 <lNhRlKrVwApE9gppn5EhaSNrLWYA9zaVO0JqEATjyK0=.8a6ffa68-c01f-474a-a267-0689b2ede1d2@github.com>
Message-ID: <HWXkt81vwIapX6VsVgIcn5Xj0sDbKXlvQAPALmkt9C4=.f5bba216-3155-4ea0-a8c9-f52b8e2d965f@github.com>

On Mon, 5 Jun 2023 19:13:30 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The VM option EnableDynamicAgentLoading was added in JDK 9, default true, to allow deployment to choose whether to allow agents to be loaded/started in the VM. The VM option does the right thing for tools using the Attach API but jcmd JVMTI.agent_load was missed. This should be fixed to disallow loading JVMTI agents when the EnableDynamicAgentLoading is false.
>> 
>> The CSR is:
>> [JDK-8309250](https://bugs.openjdk.org/browse/JDK-8309250): jcmd JVMTI.agent_load should obey EnableDynamicAgentLoading
>> 
>> Testing:
>>  - run new test `test/jdk/sun/tools/jcmd/TestJcmdNoAgentLoad.java`
>>  - TBD: submit mach5 tiers 1-5 to make sure no new regressions are introduced
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed an obsolete comment

Alan, Chris and Alex, thank you for review!

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

PR Comment: https://git.openjdk.org/jdk/pull/14244#issuecomment-1577715724

From amenkov at openjdk.org  Tue Jun  6 00:17:52 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 6 Jun 2023 00:17:52 GMT
Subject: RFR: 8309506: com/sun/jdi/MultiBreakpointsTest.java fails with
 virtual test thread factory
In-Reply-To: <IwS2fAmNudmDi-7xVY8AhB1OY1ad6jWBKZFNCBiN-VY=.685d6b39-fc0d-467b-bcf1-b758bd6ad02e@github.com>
References: <IwS2fAmNudmDi-7xVY8AhB1OY1ad6jWBKZFNCBiN-VY=.685d6b39-fc0d-467b-bcf1-b758bd6ad02e@github.com>
Message-ID: <1FarD5pLXkE9_NmVBgprY572HBMvpRTDdvevHaQHRls=.40ed74a6-032f-4b26-a1b5-b5e82813564e@github.com>

On Mon, 5 Jun 2023 22:13:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The test fails when the main debuggee thread is a virtual thread, because virtual threads are always daemon threads. Because of this all the test threads that the debuggee creates are also daemon threads. The main deuggee thread immediately exits after creating the test threads, and at that point there are no non-daemon threads left running to keep the debuggee process alive, so the test threads never get a chance to do all the work that is expected of them. 
> 
> The fix is to use Thread.join() to prevent the main test thread from exiting until all the created tests threads have exited. I also updated the test so when run using the virtual test thread factory, the debuggee test threads will now be virtual threads. Previously just the main debuggee thread would be a virtual thread. This is not a bug fix, but does provide better virtual thread testing.

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14323#pullrequestreview-1463871332

From cjplummer at openjdk.org  Tue Jun  6 00:39:59 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 6 Jun 2023 00:39:59 GMT
Subject: Withdrawn: 8309397: com/sun/jdi/JdbXXX tests fail due to not being run
 with -Djdk.trackAllThreads
In-Reply-To: <Rjxov_l1m12SNVarRfEuGYlHKQPl-OC91q6MgtHpkqU=.c7ec0949-5c8c-4604-ac49-9012689a87a7@github.com>
References: <Rjxov_l1m12SNVarRfEuGYlHKQPl-OC91q6MgtHpkqU=.c7ec0949-5c8c-4604-ac49-9012689a87a7@github.com>
Message-ID: <8IilWRrlJ6j7KLI-7NAIU5MoqAHszkXn04Rtv_yax2w=.3e732bd9-1521-4021-95b6-b5dcab38cbc3@github.com>

On Fri, 2 Jun 2023 21:41:32 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The com/sun/jdi/JdbXXX tests rely on the jdb "threads" command output to find the main thread. If it is a virtual thread, it will not be included in the "threads" output unless the debuggee is run with -Djdk.trackAllThreads, so we need to make sure to include this option when launching the debuggee. The following tests are impacted.
> 
> com/sun/jdi/JdbMethodExitTest.java
> com/sun/jdi/JdbStepTest.java
> com/sun/jdi/JdbStopThreadTest.java
> com/sun/jdi/JdbStopThreadidTest.java
> 
> Note that all these tests also fail due to [JDK-8309334](https://bugs.openjdk.org/browse/JDK-8309334), which needs to be fixed first. Also JdbMethodExitTest.java will fail due to [JDK-8309396](https://bugs.openjdk.org/browse/JDK-8309396), which should be fixed after this CR.
> 
> I've tested with mach5 tier5 in a workspace that has integrated the various CRs mentioned. Once JDK-8309334 is fixed, before integrating this PR I'll first merge and verify that the 3 tests being removed from the problem list by this PR also pass.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/14293

From cjplummer at openjdk.org  Tue Jun  6 00:44:08 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 6 Jun 2023 00:44:08 GMT
Subject: RFR: 8309510: com/sun/jdi/RedefineNestmateAttr/TestNestmateAttr.java
 no longer needs to override startup() method
Message-ID: <6kWHttu7fg50M_7FJ_zGVAbJl-UrWu6VfPMwyFCEUUk=.d6e1fcea-f821-4adb-92f4-217051c572e7@github.com>

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<String> 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.

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

Commit messages:
 - No longer need to override starupt() after JDK-8308481 fix.

Changes: https://git.openjdk.org/jdk/pull/14325/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14325&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309510
  Stats: 10 lines in 1 file changed: 0 ins; 10 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14325.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14325/head:pull/14325

PR: https://git.openjdk.org/jdk/pull/14325

From sspitsyn at openjdk.org  Tue Jun  6 01:34:26 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 Jun 2023 01:34:26 GMT
Subject: RFR: 8295976: GetThreadListStackTraces returns wrong state for blocked
 VirtualThread
Message-ID: <_bbL6afkGfa1lw1UFa26F4lGRiLQaiIkjo0tkDMUHm4=.0079cdec-34c0-45f4-836f-61118c111f43@github.com>

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 `GetSingleStackTraceClosure` and `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.
A minor refactoring of the `GetSingleStackTraceClosure` was made to fix the issue.

Also, a new test was added to provide coverage:
 - `test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest`
 
Testing:
 - ran new test: `test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest`
 - TBD: tiers 1-6

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

Commit messages:
 - remove a trailing space in new ThreadListStackTracesTest.java
 - 8295976: GetThreadListStackTraces returns wrong state for blocked VirtualThread

Changes: https://git.openjdk.org/jdk/pull/14326/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14326&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295976
  Stats: 241 lines in 5 files changed: 224 ins; 10 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/14326.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14326/head:pull/14326

PR: https://git.openjdk.org/jdk/pull/14326

From yyang at openjdk.org  Tue Jun  6 01:49:54 2023
From: yyang at openjdk.org (Yi Yang)
Date: Tue, 6 Jun 2023 01:49:54 GMT
Subject: RFR: JDK-8306441: Enhance parallel heap dump [v6]
In-Reply-To: <R5V84tAKKFgRBbieFdut8fSow6iyKQGSeLjbS4c6ReM=.2d788130-4503-4377-b865-83091227c19e@github.com>
References: <8YqPPHSW4K1s0t317Kp6UqvoGuv5v9oCbjtQ9FX8p2o=.0f6c687b-d031-401d-901d-1ec532715cdc@github.com>
 <4O3fdBsNuvwrymizPAQ1aXDMBVkHo9n841Ez5NqgY98=.28c881c8-2ae0-4736-bb25-7422ff9f60a3@github.com>
 <R5V84tAKKFgRBbieFdut8fSow6iyKQGSeLjbS4c6ReM=.2d788130-4503-4377-b865-83091227c19e@github.com>
Message-ID: <szb6dt520FpKRZ_Ol9qO5XDlgqdxhxa7x2A3GzEbt3Y=.f9369a6f-0eac-4930-9cd7-f8e360f6cadd@github.com>

On Mon, 5 Jun 2023 23:44:04 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> A lot of code movement is caused by moving AbstractDumpWriter class from heapDumper.cpp to heapDumpCompression.hpp/cpp
> I'm not happy with huge heapDumper.cpp file, but this refactoring does not look good to me.
> Currently all logic about hprof file structure is in heapDumper.cpp, it's not visible outside.
> With your fix the logic is spread in heapDumper.hpp/.cpp and heapDumpCompression.hpp/cpp

I will undo all refactor code. Let us firstly focuse on proposal itself. The refactor can be discussed later.

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

PR Comment: https://git.openjdk.org/jdk/pull/13667#issuecomment-1577770928

From yyang at openjdk.org  Tue Jun  6 02:22:33 2023
From: yyang at openjdk.org (Yi Yang)
Date: Tue, 6 Jun 2023 02:22:33 GMT
Subject: RFR: JDK-8306441: Two-stage Segmented Heap Dump [v7]
In-Reply-To: <8YqPPHSW4K1s0t317Kp6UqvoGuv5v9oCbjtQ9FX8p2o=.0f6c687b-d031-401d-901d-1ec532715cdc@github.com>
References: <8YqPPHSW4K1s0t317Kp6UqvoGuv5v9oCbjtQ9FX8p2o=.0f6c687b-d031-401d-901d-1ec532715cdc@github.com>
Message-ID: <BrymGDWqCSiBi3_2_0tQvg2ntMHXVBADfFho42FihDE=.ceb4b287-b38a-4a31-a8cf-5782b3f86742@github.com>

> ### Motivation and proposal
> Hi, heap dump brings about pauses for application's execution(STW), this is a well-known pain. JDK-8252842 have added parallel support to heapdump in an attempt to alleviate this issue. However, all concurrent threads competitively write heap data to the same file, and more memory is required to maintain the concurrent buffer queue. In experiments, we did not feel a significant performance improvement from that.
> 
> The minor-pause solution, which is presented in this PR, is a two-stage segmented heap dump:
> 
> 1. Stage One(STW): Concurrent threads directly write data to multiple heap files.
> 2. Stage Two(Non-STW): Merge multiple heap files into one complete heap dump file.
> 
> Now concurrent worker threads are not required to maintain a buffer queue, which would result in more memory overhead, nor do they need to compete for locks.
> 
> ### Performance evaluation
> | memory | numOfThread | STW         | Total      | Compression |
> | --- | --------- | -------------- | ------------ | -------- |
> | 8g | 1 thread | 15.612 secs | 15.612 secs | N |
> | 8g | 32 thread |  2.5617250 secs | 14.498 secs | N |
> | 8g | 32 thread | 2.3084878 secs | 3.198 secs | Compress1 |
> | 8g | 32 thread | 10.9355128 secs | 21.882 secs | Compress2 |
> | 8g | 96 thread | 2.6790452 secs | 14.012 secs | N |
> | 8g | 96 thread | 2.3044796 secs | 3.589 secs | Compress1 |
> | 8g | 96 thread | 9.7585151 secs | 20.219 secs| Compress2 |
> | 16g | 1 thread | 26.278 secs | 26.278 secs | N |
> | 16g | 32 thread |  5.2313740 secs | 26.417 secs | N |
> | 16g | 32 thread | 5.6946983 secs | 6.538 secs | Compress1 |
> | 16g | 32 thread | 21.8211105 secs | 41.133 secs | Compress2 |
> | 16g | 96 thread | 6.2445556 secs | 27.141 secs | N |
> | 16g | 96 thread | 4.6007096 secs | 6.259 secs | Compress1 |
> | 16g | 96 thread | 19.2965783 secs |  39.007 secs | Compress2 |
> | 32g | 1 thread | 48.149 secs | 48.149 secs | N |
> | 32g | 32 thread | 10.7734677 secs | 61.643 secs | N |
> | 32g | 32 thread | 10.1642097 secs | 10.903 secs | Compress1 |
> | 32g | 32 thread | 43.8407607 secs | 88.152 secs | Compress2 |
> | 32g | 96 thread | 13.1522042 secs | 61.432 secs | N |
> | 32g | 96 thread | 9.0954641 secs | 9.885 secs | Compress1 |
> | 32g | 96 thread | 38.9900931 secs | 80.574 secs | Compress2 |
> | 64g | 1 thread |  100.583 secs | 100.583 secs | N |
> | 64g | 32 thread | 20.9233744 secs | 134.701 secs | N |
> | 64g | 32 thread | 18.5023784 secs | 19.358 secs | Compress1 |
> | 64g | 32 thread | 86.4748377 ...

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  undo refactor

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13667/files
  - new: https://git.openjdk.org/jdk/pull/13667/files/7485e6a7..1432cdaa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13667&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13667&range=05-06

  Stats: 1332 lines in 4 files changed: 651 ins; 654 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/13667.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13667/head:pull/13667

PR: https://git.openjdk.org/jdk/pull/13667

From yyang at openjdk.org  Tue Jun  6 02:35:30 2023
From: yyang at openjdk.org (Yi Yang)
Date: Tue, 6 Jun 2023 02:35:30 GMT
Subject: RFR: JDK-8306441: Two-stage Segmented Heap Dump [v8]
In-Reply-To: <8YqPPHSW4K1s0t317Kp6UqvoGuv5v9oCbjtQ9FX8p2o=.0f6c687b-d031-401d-901d-1ec532715cdc@github.com>
References: <8YqPPHSW4K1s0t317Kp6UqvoGuv5v9oCbjtQ9FX8p2o=.0f6c687b-d031-401d-901d-1ec532715cdc@github.com>
Message-ID: <u4pUhgtGiqkZrc1J8DG6uMRgxFuJqcuAcnwDqdgBYgM=.ba48997d-340a-428b-b94d-dfbab62f4287@github.com>

> ### Motivation and proposal
> Hi, heap dump brings about pauses for application's execution(STW), this is a well-known pain. JDK-8252842 have added parallel support to heapdump in an attempt to alleviate this issue. However, all concurrent threads competitively write heap data to the same file, and more memory is required to maintain the concurrent buffer queue. In experiments, we did not feel a significant performance improvement from that.
> 
> The minor-pause solution, which is presented in this PR, is a two-stage segmented heap dump:
> 
> 1. Stage One(STW): Concurrent threads directly write data to multiple heap files.
> 2. Stage Two(Non-STW): Merge multiple heap files into one complete heap dump file.
> 
> Now concurrent worker threads are not required to maintain a buffer queue, which would result in more memory overhead, nor do they need to compete for locks.
> 
> ### Performance evaluation
> | memory | numOfThread | STW         | Total      | Compression |
> | --- | --------- | -------------- | ------------ | -------- |
> | 8g | 1 thread | 15.612 secs | 15.612 secs | N |
> | 8g | 32 thread |  2.5617250 secs | 14.498 secs | N |
> | 8g | 32 thread | 2.3084878 secs | 3.198 secs | Compress1 |
> | 8g | 32 thread | 10.9355128 secs | 21.882 secs | Compress2 |
> | 8g | 96 thread | 2.6790452 secs | 14.012 secs | N |
> | 8g | 96 thread | 2.3044796 secs | 3.589 secs | Compress1 |
> | 8g | 96 thread | 9.7585151 secs | 20.219 secs| Compress2 |
> | 16g | 1 thread | 26.278 secs | 26.278 secs | N |
> | 16g | 32 thread |  5.2313740 secs | 26.417 secs | N |
> | 16g | 32 thread | 5.6946983 secs | 6.538 secs | Compress1 |
> | 16g | 32 thread | 21.8211105 secs | 41.133 secs | Compress2 |
> | 16g | 96 thread | 6.2445556 secs | 27.141 secs | N |
> | 16g | 96 thread | 4.6007096 secs | 6.259 secs | Compress1 |
> | 16g | 96 thread | 19.2965783 secs |  39.007 secs | Compress2 |
> | 32g | 1 thread | 48.149 secs | 48.149 secs | N |
> | 32g | 32 thread | 10.7734677 secs | 61.643 secs | N |
> | 32g | 32 thread | 10.1642097 secs | 10.903 secs | Compress1 |
> | 32g | 32 thread | 43.8407607 secs | 88.152 secs | Compress2 |
> | 32g | 96 thread | 13.1522042 secs | 61.432 secs | N |
> | 32g | 96 thread | 9.0954641 secs | 9.885 secs | Compress1 |
> | 32g | 96 thread | 38.9900931 secs | 80.574 secs | Compress2 |
> | 64g | 1 thread |  100.583 secs | 100.583 secs | N |
> | 64g | 32 thread | 20.9233744 secs | 134.701 secs | N |
> | 64g | 32 thread | 18.5023784 secs | 19.358 secs | Compress1 |
> | 64g | 32 thread | 86.4748377 ...

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  undo refactor -- done

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13667/files
  - new: https://git.openjdk.org/jdk/pull/13667/files/1432cdaa..c8e80e9e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13667&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13667&range=06-07

  Stats: 53 lines in 4 files changed: 19 ins; 23 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/13667.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13667/head:pull/13667

PR: https://git.openjdk.org/jdk/pull/13667

From sspitsyn at openjdk.org  Tue Jun  6 03:09:52 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 Jun 2023 03:09:52 GMT
Subject: RFR: 8309509:
 com/sun/jdi/RedefineNestmateAttr/TestNestmateAttr.java fails with virtual test
 thread factory
In-Reply-To: <oqLBwARuJ3rFGRCxCEdnVbvNyLP1DxCHHixj5OYEJ3Y=.462f7350-24f7-4e41-9db5-8288f6c26b6d@github.com>
References: <oqLBwARuJ3rFGRCxCEdnVbvNyLP1DxCHHixj5OYEJ3Y=.462f7350-24f7-4e41-9db5-8288f6c26b6d@github.com>
Message-ID: <c6lwnOrkHNfEJlj7Fk_PSX2z8MJae1xBE87JdnwH_DI=.c84a20be-63ec-4d7f-b1f2-64d88bb0dca8@github.com>

On Tue, 6 Jun 2023 00:02:47 GMT, Chris Plummer <cjplummer at openjdk.org> 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.

Looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14324#pullrequestreview-1464169042

From sspitsyn at openjdk.org  Tue Jun  6 03:21:53 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 Jun 2023 03:21:53 GMT
Subject: RFR: 8309505: com/sun/jdi/MethodEntryExitEvents.java due to
 finding wrong main thread
In-Reply-To: <5zpDBAYAdkyhhkEzww1cgfUqHLhb7BFbd1fosEydwoQ=.4d263e58-ef38-4430-8ff0-722dec02c722@github.com>
References: <5zpDBAYAdkyhhkEzww1cgfUqHLhb7BFbd1fosEydwoQ=.4d263e58-ef38-4430-8ff0-722dec02c722@github.com>
Message-ID: <SlheECzx5LYSLqadspgy68JjsKdm_smI7ZoN-HDdc8Y=.394d4cd4-ebe3-477f-ab83-0a0e7acfff36@github.com>

On Mon, 5 Jun 2023 21:55:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The test fails because it tries to determine the main debuggee thread by allowing it run until the debuggee class is loaded (it waits for the ClassPrepareEvent). Normally this would be done on the main debuggee thread. However, when using virtual threads, the main thread has yet to spawn the virtual thread to run the test on. The test is fixed by instead just waiting until the debuggee main method is entered.
> 
> Tested by running the test locally with and without the virtual test thread wrapper, and also all of tier1 plus tier5 svc tests.

Looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14322#pullrequestreview-1464181798

From sspitsyn at openjdk.org  Tue Jun  6 04:06:52 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 Jun 2023 04:06:52 GMT
Subject: RFR: 8309510:
 com/sun/jdi/RedefineNestmateAttr/TestNestmateAttr.java no longer needs to
 override startup() method
In-Reply-To: <6kWHttu7fg50M_7FJ_zGVAbJl-UrWu6VfPMwyFCEUUk=.d6e1fcea-f821-4adb-92f4-217051c572e7@github.com>
References: <6kWHttu7fg50M_7FJ_zGVAbJl-UrWu6VfPMwyFCEUUk=.d6e1fcea-f821-4adb-92f4-217051c572e7@github.com>
Message-ID: <l-ZnnXZL-NhCQs49pcgBZfu1siU3cUHvlr8n0PhLYT4=.97e46bad-88fc-40cb-9870-676db06a2880@github.com>

On Tue, 6 Jun 2023 00:36:12 GMT, Chris Plummer <cjplummer at openjdk.org> 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<String> 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.

Looks good in general.
The test is in the `test/jdk/ProblemList-Virtual.txt` marked with the bug 8285422 which very general. Is it a good time to remove it from the problem list?

Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14325#pullrequestreview-1464220984

From sspitsyn at openjdk.org  Tue Jun  6 04:10:54 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 Jun 2023 04:10:54 GMT
Subject: RFR: 8309510:
 com/sun/jdi/RedefineNestmateAttr/TestNestmateAttr.java no longer needs to
 override startup() method
In-Reply-To: <6kWHttu7fg50M_7FJ_zGVAbJl-UrWu6VfPMwyFCEUUk=.d6e1fcea-f821-4adb-92f4-217051c572e7@github.com>
References: <6kWHttu7fg50M_7FJ_zGVAbJl-UrWu6VfPMwyFCEUUk=.d6e1fcea-f821-4adb-92f4-217051c572e7@github.com>
Message-ID: <AeHyrJ0zRUHUGZdlQ5HqXw5fPru5c2F5JNo_jfjEGHU=.c34b9c39-3946-4691-9328-a7f1f2b192d6@github.com>

On Tue, 6 Jun 2023 00:36:12 GMT, Chris Plummer <cjplummer at openjdk.org> 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<String> 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.

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14325#pullrequestreview-1464224287

From alanb at openjdk.org  Tue Jun  6 06:05:00 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 6 Jun 2023 06:05:00 GMT
Subject: RFR: 8309406: Change jdk.trackAllThreads to default to true
In-Reply-To: <tfQb4yI5onJUGBuJgLgvR-QlcXHcA850Z267aQRa4i0=.c2acbff6-d109-4e80-b981-bad41109271e@github.com>
References: <tfQb4yI5onJUGBuJgLgvR-QlcXHcA850Z267aQRa4i0=.c2acbff6-d109-4e80-b981-bad41109271e@github.com>
Message-ID: <0Y9RTCgPVUDGR8NHe925jykMIGN26CoJZcJIw9Qn4Vc=.60a9624d-bec0-4f97-9c76-9f61178557af@github.com>

On Sat, 3 Jun 2023 13:41:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Virtual threads created directly with the Thread API are not included in the new thread dump by default. This was a source of confusion in JDK 19/20 when virtual threads were in preview. We have decided to switch the default so that all virtual threads are observable. Future work will reduce/remove the overhead of tracking threads in the root container. The change proposed here has no impact to virtual threads created with the virtual ThreadPerTaskExecutor or StructuredTaskScope.
> 
> With jdk.trackAllThreads defaulting to true then the need for SharedThreadContainer to count threads can go away, as does the need for RootContainer::threads to return virtual threads blocked on I/O.
> 
> Most of the changes are to the test HotSpotDiagnosticMXBean/DumpThreads.java as this is expanded to cover more cases, and specifically more cases with thread groupings that correspond to the ThreadPerTaskExecutor and thread pools.
> 
> Testing: Test1-5

Thanks for reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/14300#issuecomment-1577964177

From alanb at openjdk.org  Tue Jun  6 06:05:02 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 6 Jun 2023 06:05:02 GMT
Subject: Integrated: 8309406: Change jdk.trackAllThreads to default to true
In-Reply-To: <tfQb4yI5onJUGBuJgLgvR-QlcXHcA850Z267aQRa4i0=.c2acbff6-d109-4e80-b981-bad41109271e@github.com>
References: <tfQb4yI5onJUGBuJgLgvR-QlcXHcA850Z267aQRa4i0=.c2acbff6-d109-4e80-b981-bad41109271e@github.com>
Message-ID: <qrdFo0mWZlkQG3BiZT7k-cvnnQ7tZr2wZX5BPiidddc=.ac5be637-dc68-434c-a960-0968aaa08afa@github.com>

On Sat, 3 Jun 2023 13:41:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Virtual threads created directly with the Thread API are not included in the new thread dump by default. This was a source of confusion in JDK 19/20 when virtual threads were in preview. We have decided to switch the default so that all virtual threads are observable. Future work will reduce/remove the overhead of tracking threads in the root container. The change proposed here has no impact to virtual threads created with the virtual ThreadPerTaskExecutor or StructuredTaskScope.
> 
> With jdk.trackAllThreads defaulting to true then the need for SharedThreadContainer to count threads can go away, as does the need for RootContainer::threads to return virtual threads blocked on I/O.
> 
> Most of the changes are to the test HotSpotDiagnosticMXBean/DumpThreads.java as this is expanded to cover more cases, and specifically more cases with thread groupings that correspond to the ThreadPerTaskExecutor and thread pools.
> 
> Testing: Test1-5

This pull request has now been integrated.

Changeset: 2e9eff56
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2e9eff56418273e85accc43dcef533995c6be8bf
Stats:     319 lines in 6 files changed: 183 ins; 81 del; 55 mod

8309406: Change jdk.trackAllThreads to default to true

Reviewed-by: rpressler, mchung, cjplummer

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

PR: https://git.openjdk.org/jdk/pull/14300

From sspitsyn at openjdk.org  Tue Jun  6 06:11:53 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 Jun 2023 06:11:53 GMT
Subject: RFR: 8309506: com/sun/jdi/MultiBreakpointsTest.java fails with
 virtual test thread factory
In-Reply-To: <IwS2fAmNudmDi-7xVY8AhB1OY1ad6jWBKZFNCBiN-VY=.685d6b39-fc0d-467b-bcf1-b758bd6ad02e@github.com>
References: <IwS2fAmNudmDi-7xVY8AhB1OY1ad6jWBKZFNCBiN-VY=.685d6b39-fc0d-467b-bcf1-b758bd6ad02e@github.com>
Message-ID: <vzEuLw1hh4E91rVNiy8tSGPzqEm9Ya_qohOFiuxtKwI=.2c3695fd-5554-43ce-8f00-13dbc07714fd@github.com>

On Mon, 5 Jun 2023 22:13:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The test fails when the main debuggee thread is a virtual thread, because virtual threads are always daemon threads. Because of this all the test threads that the debuggee creates are also daemon threads. The main deuggee thread immediately exits after creating the test threads, and at that point there are no non-daemon threads left running to keep the debuggee process alive, so the test threads never get a chance to do all the work that is expected of them. 
> 
> The fix is to use Thread.join() to prevent the main test thread from exiting until all the created tests threads have exited. I also updated the test so when run using the virtual test thread factory, the debuggee test threads will now be virtual threads. Previously just the main debuggee thread would be a virtual thread. This is not a bug fix, but does provide better virtual thread testing.

Looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14323#pullrequestreview-1464335395

From dholmes at openjdk.org  Tue Jun  6 07:32:53 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 6 Jun 2023 07:32:53 GMT
Subject: RFR: 8295976: GetThreadListStackTraces returns wrong state for
 blocked VirtualThread
In-Reply-To: <_bbL6afkGfa1lw1UFa26F4lGRiLQaiIkjo0tkDMUHm4=.0079cdec-34c0-45f4-836f-61118c111f43@github.com>
References: <_bbL6afkGfa1lw1UFa26F4lGRiLQaiIkjo0tkDMUHm4=.0079cdec-34c0-45f4-836f-61118c111f43@github.com>
Message-ID: <FYVFcG2y7HkGyCWxDT2p3fyx6sB3-9VBz978KvrSeUs=.12b426dd-b2b9-4197-a95e-8772e08c73d4@github.com>

On Tue, 6 Jun 2023 00:50:34 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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 `GetSingleStackTraceClosure` and `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.
> A minor refactoring of the `GetSingleStackTraceClosure` was made to fix the issue.
> 
> Also, a new test was added to provide coverage:
>  - `test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest`
>  
> Testing:
>  - ran new test: `test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest`
>  - TBD: tiers 1-6

Just a passing comment but I happened to notice today that when a virtual thread blocks on a legacy synchronization mechanism, it delegates to its carrier thread to report its state. It is not at all clear to me how this is handled at the JVMTI level.

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

PR Review: https://git.openjdk.org/jdk/pull/14326#pullrequestreview-1464472318

From alanb at openjdk.org  Tue Jun  6 07:42:52 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 6 Jun 2023 07:42:52 GMT
Subject: RFR: 8295976: GetThreadListStackTraces returns wrong state for
 blocked VirtualThread
In-Reply-To: <FYVFcG2y7HkGyCWxDT2p3fyx6sB3-9VBz978KvrSeUs=.12b426dd-b2b9-4197-a95e-8772e08c73d4@github.com>
References: <_bbL6afkGfa1lw1UFa26F4lGRiLQaiIkjo0tkDMUHm4=.0079cdec-34c0-45f4-836f-61118c111f43@github.com>
 <FYVFcG2y7HkGyCWxDT2p3fyx6sB3-9VBz978KvrSeUs=.12b426dd-b2b9-4197-a95e-8772e08c73d4@github.com>
Message-ID: <4CPJ19jOAYq8cQqJWqGRgwO-kbLv0glRGTna0FY4jtE=.c1ca455b-80f6-47e9-ba37-1db3b33bb95c@github.com>

On Tue, 6 Jun 2023 07:30:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Just a passing comment but I happened to notice today that when a virtual thread blocks on a legacy synchronization mechanism, it delegates to its carrier thread to report its state. It is not at all clear to me how this is handled at the JVMTI level.

When mounted, the virtual thread state comes from its carrier. JVM TI GetThreadState and other functions that return state do the same. Somehow the bulk function GetThreadListStackTraces was missed.

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

PR Comment: https://git.openjdk.org/jdk/pull/14326#issuecomment-1578097719

From duke at openjdk.org  Tue Jun  6 09:58:54 2023
From: duke at openjdk.org (JoKern65)
Date: Tue, 6 Jun 2023 09:58:54 GMT
Subject: RFR: JDK-8309462:
 vmTestbase/nsk/jvmti/RunAgentThread/agentthr001/TestDescription.java crashing
 due to empty while loop
Message-ID: <XLSnFyCggsHJL-YGgwO1icLhcDc-gFX98AR3NR8wB0Y=.024c3b61-79d2-42a6-a38e-517233c23091@github.com>

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 <unistd.h>`
`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) {`
`     }`
`}`

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

Commit messages:
 - JDK-8309462

Changes: https://git.openjdk.org/jdk/pull/14330/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14330&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309462
  Stats: 2 lines in 1 file changed: 2 ins; 0 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

From alanb at openjdk.org  Tue Jun  6 10:12:54 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 6 Jun 2023 10:12:54 GMT
Subject: RFR: 8309408: Thread.sleep cleanup
In-Reply-To: <kQ3W95PGzZJZlAETD5X1vZLJrr2D6MQaUGYuANKzPEU=.8f8e19b2-d2d4-462e-b05f-b608e69549b8@github.com>
References: <aQgYdV9yETAis_U44TCaI5C5MTR4DMMD-5Li28_cbvc=.6d65e000-4b13-4f27-a7d8-e6854e99337f@github.com>
 <s4RVxlZSY-yAzXf20pgbaAL1MHvqtj28REIM2j2cVbY=.0015b333-a3e6-4e84-920a-278a534ab279@github.com>
 <WKHpH37ZatpB7C-Cg-8UDD0M7OEwWukcwgj5udvrkVU=.ee704a1a-4824-4e1c-977b-c73530eda53b@github.com>
 <kQ3W95PGzZJZlAETD5X1vZLJrr2D6MQaUGYuANKzPEU=.8f8e19b2-d2d4-462e-b05f-b608e69549b8@github.com>
Message-ID: <8l9FG4c1c4Ydlv3gQBiramw0YpSthxC-4wXOxVWiIOE=.b14f4319-2ecf-47ea-8118-5a3fe60d92c2@github.com>

On Mon, 5 Jun 2023 20:05:24 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The following commit in loom heavily modified this file with a lot of added expected methods. There are other related tests with similar changes. I'm not so sure I understand the need for so many additions, and also why expectedLength is so out of sync with the number of added method. I don't believe this commit was reviewed individually, but was just part of the overall loom review when merge into jdk. Perhaps it should be revisited.

These tests aren't easy to read or maintain, it would be good to re-visit them. In some cases, the tests capture the stack trace asynchronously so the test needs to know about all code paths.

As regards ThreadController, used by the nsk/monitoring/stress/thread/straceXXX tests, the main thread waits at a barrier (a CountDownLatch) until all sleeping threads are ready to sleep. Once the main thread is released, it checks all the sleepers are in TIMED_WAITING state and samples their stack traces with the ThreadMXBean and related APIs. The test fails if there are frames corresponding to methods that the test doesn't know about. If a thread is sleeping then we shouldn't see frames for beforeSleep/afterSlee. My reading of these tests is that the main thread could poll a SleepingThread after it counts down and before it parks in sleep. It's doing an expensive ThreadMXBean::getAllThreadIds once released and that may explain why it hasn't been seen.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14303#discussion_r1219348675

From mbaesken at openjdk.org  Tue Jun  6 10:24:52 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 6 Jun 2023 10:24:52 GMT
Subject: RFR: JDK-8309462:
 vmTestbase/nsk/jvmti/RunAgentThread/agentthr001/TestDescription.java crashing
 due to empty while loop
In-Reply-To: <XLSnFyCggsHJL-YGgwO1icLhcDc-gFX98AR3NR8wB0Y=.024c3b61-79d2-42a6-a38e-517233c23091@github.com>
References: <XLSnFyCggsHJL-YGgwO1icLhcDc-gFX98AR3NR8wB0Y=.024c3b61-79d2-42a6-a38e-517233c23091@github.com>
Message-ID: <dF0KLXsUimmtQTqGmVfAI51kC1loOvLglRuUbZMNHA8=.96237849-6e17-4e10-8f06-4548ced11f82@github.com>

On Tue, 6 Jun 2023 09:51:09 GMT, JoKern65 <duke at openjdk.org> 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 <unistd.h>`
> `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) {`
> `     }`
> `}`

looks okay to me

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

Marked as reviewed by mbaesken (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14330#pullrequestreview-1464841555

From liach at openjdk.org  Tue Jun  6 11:16:57 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 6 Jun 2023 11:16:57 GMT
Subject: RFR: 8294977: Convert test/jdk/java tests from ASM library to
 Classfile API [v8]
In-Reply-To: <gotPxtkGGDqNkx5908vAQvuXufrubBUh6sxYK-CKgbI=.82b77e30-f114-418c-9ab6-4ea0d33eafc0@github.com>
References: <ZNm0kG5HiHCfixYeCz0EGjsT7ejmvPsXxN36-vAwQsU=.3eec9170-96da-444e-ad10-0095597b4fef@github.com>
 <gotPxtkGGDqNkx5908vAQvuXufrubBUh6sxYK-CKgbI=.82b77e30-f114-418c-9ab6-4ea0d33eafc0@github.com>
Message-ID: <J3k7ZSn4ZLJOjiFIPW8nNXMB4g3chGGGPS6B3DjI8p0=.a99462a9-fd0d-4895-bc2a-2e53aceb42db@github.com>

On Tue, 9 May 2023 04:17:28 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Summaries:
>> 1. A few recommendations about updating the constant API is made at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html and I may update this patch shall the API changes be integrated before
>> 2. One ASM library-specific test, `LambdaAsm` is removed. Others have their code generation infrastructure upgraded from ASM to Classfile API.
>> 3. Most tests are included in tier1, but some are not:
>> In `:jdk_io`: (tier2, part 2)
>> 
>> test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java
>> test/jdk/java/io/Serializable/records/ProhibitedMethods.java
>> test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java
>> 
>> In `:jdk_instrument`: (tier 3)
>> 
>> test/jdk/java/lang/instrument/RetransformAgent.java
>> test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java
>> test/jdk/java/lang/instrument/asmlib/Instrumentor.java
>> 
>> 
>> @asotona Would you mind reviewing?
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge branch 'master' into invoke-test-classfile
>  - Switch to ConstantDescs for <init> <clinit> and void constants
>  - Merge AnnotationsTest, remove ModuleTargetAttribute call
>  - Merge branch 'invoke-test-classfile' of https://github.com/liachmodded/jdk into invoke-test-classfile
>  - Update test/jdk/java/lang/invoke/8022701/MHIllegalAccess.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Merge branch 'master' into invoke-test-classfile
>  - Fix LambdaStackTrace after running
>  - formatting
>  - Fix failed LambdaStackTrace test, use more convenient APIs
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into invoke-test-classfile
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/d9052b94...5db1e957

keep-alive; this will be updated for the classfile object update.

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

PR Comment: https://git.openjdk.org/jdk/pull/13009#issuecomment-1578507931

From mdoerr at openjdk.org  Tue Jun  6 12:10:52 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 6 Jun 2023 12:10:52 GMT
Subject: RFR: JDK-8309462:
 vmTestbase/nsk/jvmti/RunAgentThread/agentthr001/TestDescription.java crashing
 due to empty while loop
In-Reply-To: <XLSnFyCggsHJL-YGgwO1icLhcDc-gFX98AR3NR8wB0Y=.024c3b61-79d2-42a6-a38e-517233c23091@github.com>
References: <XLSnFyCggsHJL-YGgwO1icLhcDc-gFX98AR3NR8wB0Y=.024c3b61-79d2-42a6-a38e-517233c23091@github.com>
Message-ID: <OJbCL6SwNHxhpQRe62uuIPorx5u5l4Z6bvOOyvLWl7c=.d4e8d240-b671-4b72-881e-3369271486ba@github.com>

On Tue, 6 Jun 2023 09:51:09 GMT, JoKern65 <duke at openjdk.org> 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 <unistd.h>`
> `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) {`
> `     }`
> `}`

LGTM. `sleep(1)` is my preferred solution. Thanks for fixing it!

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14330#pullrequestreview-1465026778

From stuefe at openjdk.org  Tue Jun  6 12:44:13 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 6 Jun 2023 12:44:13 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v5]
In-Reply-To: <fcRlEmBBI3U8CovyR6Sp0qt49jlim5s6SdXAlpAx_tM=.a3102b4e-decd-4068-9cb5-8fa6fe6708f8@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <fcRlEmBBI3U8CovyR6Sp0qt49jlim5s6SdXAlpAx_tM=.a3102b4e-decd-4068-9cb5-8fa6fe6708f8@github.com>
Message-ID: <LHqu7G9E-C18vtES7ZeyJsLfyfenqjBY4GKWnG3gbIU=.0e0d0ac2-3013-487b-a529-a2a566dd8eff@github.com>

On Sun, 4 Jun 2023 21:39:58 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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 three asserts making comparisons between atomic volatile variables
>   
>   Though changes to the volatile variables are individually protected by
>   Atomic load and store operations, these asserts were not assuring
>   atomic access to multiple volatile variables, each of which could be
>   modified independently of the others.  The asserts were therefore not
>   trustworthy, as has been confirmed by more extensive testing.

Hi @kdnilsen,

I see that following settings changed default values for all of Shenandoah:

- ShenandoahLearningSteps (was 10, now 5)
- ShenandoahImmediateThreshold (was 90, now 70)
- ShenandoahAdaptiveDecayFactor (was 0.5, now 0.1)
- ShenandoahFullGCThreshold (was 3, now 64)

Assuming that the behavior of legacy Shenandoah remains unchanged, I assume the switches are now handled differently to arrive at the same behavior.

I see that we now have ShenandoahOOMGCRetries. Does the changed default for ShenandoahFullGCThreshold and this new ShenandoahOOMGCRetries switch mean the degeneration behavior of legacy Shenandoah did change?

I think the general thrust of my questions is, you assured us that legacy Shenandoah will show the same behavior post-patch, but since the settings changed, I assume that the meaning of these settings did change. We will need to document these effects for users of legacy Shenandoah, in case they need to translate existing settings in their environment. A release note would be really helpful.

Cheers, Thomas

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

PR Comment: https://git.openjdk.org/jdk/pull/14185#issuecomment-1578693858

From mdoerr at openjdk.org  Tue Jun  6 12:58:56 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 6 Jun 2023 12:58:56 GMT
Subject: RFR: JDK-8309225: Fix xlc17 clang 15 warnings in security and
 servicability
In-Reply-To: <TVjM9BfpfntsYda5nA4AcZazR-O8Mjl1SyTFu-Bmtpo=.d407a6a1-a865-49ea-8a58-deba1ba11d0c@github.com>
References: <TVjM9BfpfntsYda5nA4AcZazR-O8Mjl1SyTFu-Bmtpo=.d407a6a1-a865-49ea-8a58-deba1ba11d0c@github.com>
Message-ID: <R7S8WmrFogK0BgT1qxX6MU-8T5gZABzrYl8_q4srD1E=.9ffc952f-1fbd-4ea1-8f9a-aeb845d22305@github.com>

On Fri, 2 Jun 2023 10:19:53 GMT, JoKern65 <duke at openjdk.org> 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}

LGTM.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14282#pullrequestreview-1465140605

From sspitsyn at openjdk.org  Tue Jun  6 13:31:11 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 Jun 2023 13:31:11 GMT
Subject: RFR: 8295976: GetThreadListStackTraces returns wrong state for
 blocked VirtualThread [v2]
In-Reply-To: <_bbL6afkGfa1lw1UFa26F4lGRiLQaiIkjo0tkDMUHm4=.0079cdec-34c0-45f4-836f-61118c111f43@github.com>
References: <_bbL6afkGfa1lw1UFa26F4lGRiLQaiIkjo0tkDMUHm4=.0079cdec-34c0-45f4-836f-61118c111f43@github.com>
Message-ID: <Cknmpp_Fd6jNPVuBcovaDn9P7rvKVO0-E3ndCPzwSfI=.afe89918-3ca7-457e-9d26-2a66ffa15a01@github.com>

> 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 `GetSingleStackTraceClosure` and `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.
> A minor refactoring of the `GetSingleStackTraceClosure` was made to fix the issue.
> 
> Also, a new test was added to provide coverage:
>  - `test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest`
>  
> Testing:
>  - ran new test: `test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest`
>  - TBD: tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  simplify GetSingleStackTraceClosure, fix issue in VM_GetThreadListStackTraces::doit, improve test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14326/files
  - new: https://git.openjdk.org/jdk/pull/14326/files/77718470..4e794bd5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14326&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14326&range=00-01

  Stats: 27 lines in 4 files changed: 11 ins; 5 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/14326.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14326/head:pull/14326

PR: https://git.openjdk.org/jdk/pull/14326

From sspitsyn at openjdk.org  Tue Jun  6 13:37:03 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 Jun 2023 13:37:03 GMT
Subject: RFR: 8295976: GetThreadListStackTraces returns wrong state for
 blocked VirtualThread [v3]
In-Reply-To: <_bbL6afkGfa1lw1UFa26F4lGRiLQaiIkjo0tkDMUHm4=.0079cdec-34c0-45f4-836f-61118c111f43@github.com>
References: <_bbL6afkGfa1lw1UFa26F4lGRiLQaiIkjo0tkDMUHm4=.0079cdec-34c0-45f4-836f-61118c111f43@github.com>
Message-ID: <c2jVJSXHGbLFkSUCvqaU96NHE-UyF9vb6oATGM94I3k=.83797f52-90af-45e5-aea3-5ee20489e87b@github.com>

> 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 `GetSingleStackTraceClosure` and `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.
> A minor refactoring of the `GetSingleStackTraceClosure` was made to fix the issue.
> 
> Also, a new test was added to provide coverage:
>  - `test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest`
>  
> Testing:
>  - ran new test: `test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest`
>  - TBD: tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with two additional commits since the last revision:

 - fixed typo in a comment in jvmtiEnvBase.cpp
 - nit: restored one comment as was before

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14326/files
  - new: https://git.openjdk.org/jdk/pull/14326/files/4e794bd5..d20e1221

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14326&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14326&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14326.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14326/head:pull/14326

PR: https://git.openjdk.org/jdk/pull/14326

From kdnilsen at openjdk.org  Tue Jun  6 13:48:18 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 6 Jun 2023 13:48:18 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v5]
In-Reply-To: <fcRlEmBBI3U8CovyR6Sp0qt49jlim5s6SdXAlpAx_tM=.a3102b4e-decd-4068-9cb5-8fa6fe6708f8@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <fcRlEmBBI3U8CovyR6Sp0qt49jlim5s6SdXAlpAx_tM=.a3102b4e-decd-4068-9cb5-8fa6fe6708f8@github.com>
Message-ID: <28NBsNni8p68iy2K_TjXIC1oScdrAtyK-NJd5OH0gVc=.c4adc4a5-82c9-4afa-b1a9-9e5b99b2ecdd@github.com>

On Sun, 4 Jun 2023 21:39:58 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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 three asserts making comparisons between atomic volatile variables
>   
>   Though changes to the volatile variables are individually protected by
>   Atomic load and store operations, these asserts were not assuring
>   atomic access to multiple volatile variables, each of which could be
>   modified independently of the others.  The asserts were therefore not
>   trustworthy, as has been confirmed by more extensive testing.

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:

* Decrease ShenandoahLearningSteps to 5 (from 10): For some workloads, we observed that there were "way too many" learning cycles being triggered.  We also observed that the learning achieved during learning cycles was not as trustworthy as the learning achieved during actual operation, because these learning cycles typically trigger during initialization phases which are not representative of real-world operation and because they usually trigger so prematurely that there has not been enough time for allocated objects to die before we garbage collect.
* Change ShenandoahImmediateThreshold to 70 from 90: We discovered during experiments with settings on certain real production workloads that reducing the threshold for abbreviated cycles significantly improved throughput, reduced degenerated cycles, and reduced high percentile end-to-end latency on the relevant services.  These experiments were based on single-generation Shenandoah.  We saw no negative impact of making this change on our various workloads.
 * I'll let @earthling-amzn comment on the change to ShenandoahAdaptiveDecayFactor.  My recollection is that this change was also motivated by experience with single-generation Shenandoah on a real production workload.
 * The change of ShenandoahFullGCThreshold from 3 to 64 was motivated by some observations with specjbb performance as it ratchets up the workload to determine MaxJOPS.  We observed that for both single-generation Shenandoah and generational Shenandoah, the typical behavior was that a single Full GC trigger causes an "infinite" sequence of Full GC, even though we may have only lost the concurrent GC race by a small amount.  This is because (1) Full GC discards all the incremental work of the concurrent GC that was just interrupted, (2) STW Full GC creates a situation in which pent up demand for execution and allocation accumulates during the STW pause so there's a huge demand for allocation immediately following the end of Full GC, (3) The concurrent GC that triggers immediately after Full GC completes is "destined" to fail because no garbage has been introduced since Full GC finished and since SATB does not collect floating garbage that accumulates after the start of concurrent GC a
 nd since the allocation spike is so high immediately following the Full GC (e.g. 11GB/s instead of 3GB/s normally).  This change allows a sequence of degenerated GCs to manage slow evolution and sudden bursts of allocation rate much more effectively than the original code.  This is accompanied by a change in how we detect and throw OOM.  We wait for at least one Full GC but we don't force ShenandoahFullGCThreshold allocation failures before thowing OOM.

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

PR Comment: https://git.openjdk.org/jdk/pull/14185#issuecomment-1578800487

From jwaters at openjdk.org  Tue Jun  6 15:37:00 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 6 Jun 2023 15:37:00 GMT
Subject: RFR: 8305341: Alignment should be enforced by alignas instead of
 compiler specific attributes [v4]
In-Reply-To: <dlMKfkRoYlEOlABs5J-mW-Mbr-M3Kv455fgrnmj0A1w=.954ab66c-6dfb-44e7-9546-455e38e35f4a@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
 <dlMKfkRoYlEOlABs5J-mW-Mbr-M3Kv455fgrnmj0A1w=.954ab66c-6dfb-44e7-9546-455e38e35f4a@github.com>
Message-ID: <lc5jVajW_m2sFNWLyspQPgPHIzmU9vgzuH9gKmpSCys=.98210314-df7b-4179-a71d-5c5aeedd0c52@github.com>

On Wed, 12 Apr 2023 07:12:10 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements
>
> Julian Waters has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Restore visCPP
>  - Restore gcc attribute
>  - Revert gcc
>  - Revert

Bumping

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

PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1578994674

From wkemper at openjdk.org  Tue Jun  6 15:44:15 2023
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 6 Jun 2023 15:44:15 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v5]
In-Reply-To: <fcRlEmBBI3U8CovyR6Sp0qt49jlim5s6SdXAlpAx_tM=.a3102b4e-decd-4068-9cb5-8fa6fe6708f8@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <fcRlEmBBI3U8CovyR6Sp0qt49jlim5s6SdXAlpAx_tM=.a3102b4e-decd-4068-9cb5-8fa6fe6708f8@github.com>
Message-ID: <N2kO5G4pRGGZBql4DdXRJU4q2_zIc7bSY4f6KnwuPns=.d789c12d-0240-441e-a7e4-0d7bfec9eae3@github.com>

On Sun, 4 Jun 2023 21:39:58 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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 three asserts making comparisons between atomic volatile variables
>   
>   Though changes to the volatile variables are individually protected by
>   Atomic load and store operations, these asserts were not assuring
>   atomic access to multiple volatile variables, each of which could be
>   modified independently of the others.  The asserts were therefore not
>   trustworthy, as has been confirmed by more extensive testing.

Lowering `ShenandoahAdaptiveDecayFactor` allows the heuristic to give more weight to older samples of the allocation rate and cycle times. We found that with the original value (0.5), the heuristics would "forget" history too soon. With the original value, the heuristics were more likely to mistime their trigger because of a few recent, short cycles. This was particularly true after we lowered `ShenandoahImmediateThreshold`, which resulted in more cycles which could skip evacuation and updating refs.

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

PR Comment: https://git.openjdk.org/jdk/pull/14185#issuecomment-1579008730

From alanb at openjdk.org  Tue Jun  6 15:45:57 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 6 Jun 2023 15:45:57 GMT
Subject: RFR: 8307153: JVMTI GetThreadState on carrier should return
 STATE_WAITING [v2]
In-Reply-To: <chf9KOskdhm96pUVVgA9gIS2aPHPTnHQ3cAAjDRYJV4=.331b1bdd-3dc5-4f4a-ba15-9514f8b39ee6@github.com>
References: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>
 <SH2pr7y0t3C1v3EFDfgS4AArNAxNXbb1LTPC6xrKGI8=.2a629523-a681-4b61-988f-4df5e60e7a2b@github.com>
 <t-iQRZCgi0Jv6fpJDBRLID3Bhll-2ezYbVHfC7u79N0=.4db46ff4-351e-4737-81fb-b66ebb4358ed@github.com>
 <MkJ9Qmy6wtW_uzB2VXyFbfMujlzTgF_Tc_DM6n0z9HU=.de134484-9fa3-4ac9-a68f-5a2b3b5be59c@github.com>
 <chf9KOskdhm96pUVVgA9gIS2aPHPTnHQ3cAAjDRYJV4=.331b1bdd-3dc5-4f4a-ba15-9514f8b39ee6@github.com>
Message-ID: <jRansukCg6_vwIh6V_bBvJu52yCBeczPELl4KEaKxmA=.61870be5-8131-46b8-ad93-e123e9027dff@github.com>

On Mon, 5 Jun 2023 21:26:39 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Okay, I see you point. Unfortunately, I've always referred the platform thread with an executed FJP schedular as a carrier thread. The term 'carrier' with this meaning is everywhere in the JVMTI code. It looks very confusing to call a thread to be a carrier thread only during some phases of its execution.

Okay, I'm just pointing out that is_passive_carrier_thread is confusing looks a bit strange here as the is testing if a JavaThread is carrying a virtual thread oop -  it's not testing if the thread is owned by the virtual thread scheduler.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14298#discussion_r1219888219

From asemenov at openjdk.org  Tue Jun  6 17:35:34 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Tue, 6 Jun 2023 17:35:34 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v3]
In-Reply-To: <A6_DjU6Oy1FQ2jv01AAzEvvtbwyIZzbqhrc-qG-Lfh8=.b6ee5527-f523-42b6-ae40-f7c14ee797f7@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <CKiRtl0qFJAta3S3Ysa1wQHfQI34FDAW6qLvb8p336U=.2f3cfe22-b050-4483-b95b-b53aa8e2e78d@github.com>
 <XCV9wPHhv83rnla_Y8LoBYJ9EdcQfuAlClsvp01vHdg=.d8982ce2-253e-4ba5-93f5-ca12c489c38b@github.com>
 <CnZGN1jj91T015K1ywlKfrv0xj-eRKVJMd2iayTSXWg=.a6386461-e844-480a-b351-901cfb945be5@github.com>
 <A6_DjU6Oy1FQ2jv01AAzEvvtbwyIZzbqhrc-qG-Lfh8=.b6ee5527-f523-42b6-ae40-f7c14ee797f7@github.com>
Message-ID: <kVqgGub33GeB4hq2vRW7vxiObaD_DbXICbsv8-NoFiU=.aaf4825e-d820-496d-8faa-cede92c21323@github.com>

On Thu, 1 Jun 2023 15:04:09 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> done
>
> I didn't ask to revert the change. It's `s/TARGET_OS_MAC/defined(__APPLE__)/`.

This is rarely used in the code and is not the essence of the current changes.
If you introduce such changes, then throughout the code.
Moreover, this can lead to problems, such as, for example, here: https://bugs.openjdk.org/browse/JDK-8309225

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1220056527

From weijun at openjdk.org  Tue Jun  6 17:50:00 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 6 Jun 2023 17:50:00 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v3]
In-Reply-To: <kVqgGub33GeB4hq2vRW7vxiObaD_DbXICbsv8-NoFiU=.aaf4825e-d820-496d-8faa-cede92c21323@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <CKiRtl0qFJAta3S3Ysa1wQHfQI34FDAW6qLvb8p336U=.2f3cfe22-b050-4483-b95b-b53aa8e2e78d@github.com>
 <XCV9wPHhv83rnla_Y8LoBYJ9EdcQfuAlClsvp01vHdg=.d8982ce2-253e-4ba5-93f5-ca12c489c38b@github.com>
 <CnZGN1jj91T015K1ywlKfrv0xj-eRKVJMd2iayTSXWg=.a6386461-e844-480a-b351-901cfb945be5@github.com>
 <A6_DjU6Oy1FQ2jv01AAzEvvtbwyIZzbqhrc-qG-Lfh8=.b6ee5527-f523-42b6-ae40-f7c14ee797f7@github.com>
 <kVqgGub33GeB4hq2vRW7vxiObaD_DbXICbsv8-NoFiU=.aaf4825e-d820-496d-8faa-cede92c21323@github.com>
Message-ID: <xZ74zHbqffVTsEOGXk2t1cSOOG1uX9fZ6CruSac9U4k=.79254c0b-1947-4911-bdbc-5abae651e950@github.com>

On Tue, 6 Jun 2023 17:32:35 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> I didn't ask to revert the change. It's `s/TARGET_OS_MAC/defined(__APPLE__)/`.
>
> This is rarely used in the code and is not the essence of the current changes.
> If you introduce such changes, then throughout the code.
> Moreover, this can lead to problems, such as, for example, here: https://bugs.openjdk.org/browse/JDK-8309225

I'm not a clang expect, I was just asking if modifying the current `#if TARGET_OS_MAC` check into `#if defined(__APPLE__)` is also a solution. The comment on lines 46-47 says the condition was copied from a macOS SDK file and that's what the file is using now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1220071779

From cjplummer at openjdk.org  Tue Jun  6 18:20:08 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 6 Jun 2023 18:20:08 GMT
Subject: RFR: 8309506: com/sun/jdi/MultiBreakpointsTest.java fails with
 virtual test thread factory
In-Reply-To: <IwS2fAmNudmDi-7xVY8AhB1OY1ad6jWBKZFNCBiN-VY=.685d6b39-fc0d-467b-bcf1-b758bd6ad02e@github.com>
References: <IwS2fAmNudmDi-7xVY8AhB1OY1ad6jWBKZFNCBiN-VY=.685d6b39-fc0d-467b-bcf1-b758bd6ad02e@github.com>
Message-ID: <r3NY8ckG6jvsy3Ju9kKf8XogQBzqBZel6nX_0UimaQ0=.6eee5d8f-7b7e-457f-9b71-179bd0529233@github.com>

On Mon, 5 Jun 2023 22:13:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The test fails when the main debuggee thread is a virtual thread, because virtual threads are always daemon threads. Because of this all the test threads that the debuggee creates are also daemon threads. The main deuggee thread immediately exits after creating the test threads, and at that point there are no non-daemon threads left running to keep the debuggee process alive, so the test threads never get a chance to do all the work that is expected of them. 
> 
> The fix is to use Thread.join() to prevent the main test thread from exiting until all the created tests threads have exited. I also updated the test so when run using the virtual test thread factory, the debuggee test threads will now be virtual threads. Previously just the main debuggee thread would be a virtual thread. This is not a bug fix, but does provide better virtual thread testing.

Thanks for the reviews Alex and Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/14323#issuecomment-1579243690

From cjplummer at openjdk.org  Tue Jun  6 18:20:11 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 6 Jun 2023 18:20:11 GMT
Subject: Integrated: 8309506: com/sun/jdi/MultiBreakpointsTest.java fails with
 virtual test thread factory
In-Reply-To: <IwS2fAmNudmDi-7xVY8AhB1OY1ad6jWBKZFNCBiN-VY=.685d6b39-fc0d-467b-bcf1-b758bd6ad02e@github.com>
References: <IwS2fAmNudmDi-7xVY8AhB1OY1ad6jWBKZFNCBiN-VY=.685d6b39-fc0d-467b-bcf1-b758bd6ad02e@github.com>
Message-ID: <1UoNIjR2ZKcfI8wUHZuermi6dRtmQOih1tLTvMrJt90=.cc498b09-8c37-4aa5-a41f-e31737c4884f@github.com>

On Mon, 5 Jun 2023 22:13:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The test fails when the main debuggee thread is a virtual thread, because virtual threads are always daemon threads. Because of this all the test threads that the debuggee creates are also daemon threads. The main deuggee thread immediately exits after creating the test threads, and at that point there are no non-daemon threads left running to keep the debuggee process alive, so the test threads never get a chance to do all the work that is expected of them. 
> 
> The fix is to use Thread.join() to prevent the main test thread from exiting until all the created tests threads have exited. I also updated the test so when run using the virtual test thread factory, the debuggee test threads will now be virtual threads. Previously just the main debuggee thread would be a virtual thread. This is not a bug fix, but does provide better virtual thread testing.

This pull request has now been integrated.

Changeset: 571fbdc3
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/571fbdc3110440ec3a36bb6005dc5a0358696df5
Stats:     16 lines in 2 files changed: 10 ins; 2 del; 4 mod

8309506: com/sun/jdi/MultiBreakpointsTest.java fails with virtual test thread factory

Reviewed-by: amenkov, sspitsyn

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

PR: https://git.openjdk.org/jdk/pull/14323

From cjplummer at openjdk.org  Tue Jun  6 18:31:54 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 6 Jun 2023 18:31:54 GMT
Subject: RFR: 8309505: com/sun/jdi/MethodEntryExitEvents.java due to
 finding wrong main thread
In-Reply-To: <5zpDBAYAdkyhhkEzww1cgfUqHLhb7BFbd1fosEydwoQ=.4d263e58-ef38-4430-8ff0-722dec02c722@github.com>
References: <5zpDBAYAdkyhhkEzww1cgfUqHLhb7BFbd1fosEydwoQ=.4d263e58-ef38-4430-8ff0-722dec02c722@github.com>
Message-ID: <FdABYeceAYM-pFW_INRuaBDSWg4892xo-J818Hkzqm8=.f450adff-d040-480d-ba12-e385831e16af@github.com>

On Mon, 5 Jun 2023 21:55:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The test fails because it tries to determine the main debuggee thread by allowing it run until the debuggee class is loaded (it waits for the ClassPrepareEvent). Normally this would be done on the main debuggee thread. However, when using virtual threads, the main thread has yet to spawn the virtual thread to run the test on. The test is fixed by instead just waiting until the debuggee main method is entered.
> 
> Tested by running the test locally with and without the virtual test thread wrapper, and also all of tier1 plus tier5 svc tests.

Thanks for the reviews Alex and Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/14322#issuecomment-1579258734

From cjplummer at openjdk.org  Tue Jun  6 18:38:17 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 6 Jun 2023 18:38:17 GMT
Subject: Integrated: 8309505: com/sun/jdi/MethodEntryExitEvents.java due to
 finding wrong main thread
In-Reply-To: <5zpDBAYAdkyhhkEzww1cgfUqHLhb7BFbd1fosEydwoQ=.4d263e58-ef38-4430-8ff0-722dec02c722@github.com>
References: <5zpDBAYAdkyhhkEzww1cgfUqHLhb7BFbd1fosEydwoQ=.4d263e58-ef38-4430-8ff0-722dec02c722@github.com>
Message-ID: <lX9Il1bAZ1NiG701luKTNEtQ4ZrLHO0dPnQ4w3zZtRk=.0d03c6e0-8f0e-453b-9392-6b9c6a09dbc5@github.com>

On Mon, 5 Jun 2023 21:55:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The test fails because it tries to determine the main debuggee thread by allowing it run until the debuggee class is loaded (it waits for the ClassPrepareEvent). Normally this would be done on the main debuggee thread. However, when using virtual threads, the main thread has yet to spawn the virtual thread to run the test on. The test is fixed by instead just waiting until the debuggee main method is entered.
> 
> Tested by running the test locally with and without the virtual test thread wrapper, and also all of tier1 plus tier5 svc tests.

This pull request has now been integrated.

Changeset: 16ab7bfe
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/16ab7bfe22b96ec8c4b7b7197d55fa41d36e3875
Stats:     7 lines in 2 files changed: 1 ins; 1 del; 5 mod

8309505: com/sun/jdi/MethodEntryExitEvents.java due to finding wrong main thread

Reviewed-by: amenkov, sspitsyn

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

PR: https://git.openjdk.org/jdk/pull/14322

From cjplummer at openjdk.org  Tue Jun  6 18:38:16 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 6 Jun 2023 18:38:16 GMT
Subject: RFR: 8309505: com/sun/jdi/MethodEntryExitEvents.java due to
 finding wrong main thread [v2]
In-Reply-To: <5zpDBAYAdkyhhkEzww1cgfUqHLhb7BFbd1fosEydwoQ=.4d263e58-ef38-4430-8ff0-722dec02c722@github.com>
References: <5zpDBAYAdkyhhkEzww1cgfUqHLhb7BFbd1fosEydwoQ=.4d263e58-ef38-4430-8ff0-722dec02c722@github.com>
Message-ID: <s5qiXkDKLTJRxoLAlMRGca_tx4Kd43xk0h58E0sC6gE=.1f0d7200-3068-4f75-9a38-619793fa9b5d@github.com>

> The test fails because it tries to determine the main debuggee thread by allowing it run until the debuggee class is loaded (it waits for the ClassPrepareEvent). Normally this would be done on the main debuggee thread. However, when using virtual threads, the main thread has yet to spawn the virtual thread to run the test on. The test is fixed by instead just waiting until the debuggee main method is entered.
> 
> Tested by running the test locally with and without the virtual test thread wrapper, and also all of tier1 plus tier5 svc tests.

Chris Plummer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge
 - Fix virtual thread testing issue by waiting until debuggee main method is entered before gleaning the main thread.

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

Changes: https://git.openjdk.org/jdk/pull/14322/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14322&range=01
  Stats: 7 lines in 2 files changed: 1 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14322.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14322/head:pull/14322

PR: https://git.openjdk.org/jdk/pull/14322

From sspitsyn at openjdk.org  Tue Jun  6 18:42:59 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 Jun 2023 18:42:59 GMT
Subject: RFR: 8309396: com/sun/jdi/JdbMethodExitTest.java fails with
 virtual threads due to a bug in determining the main thread id [v2]
In-Reply-To: <eYT7Ufm_eWge731leRG6LHFg6iZeEMDZNOIkEVlw3ws=.5c0a0cc9-a9c3-42b0-a7fc-c21f24ef3433@github.com>
References: <_rWgi41CJ8newOTI2hqbjeNgOCCDTnNq030O6wXi_RI=.436a6404-306a-4001-b193-1206ee40f85d@github.com>
 <eYT7Ufm_eWge731leRG6LHFg6iZeEMDZNOIkEVlw3ws=.5c0a0cc9-a9c3-42b0-a7fc-c21f24ef3433@github.com>
Message-ID: <m1-d5SCj8bMEfqALWBMKahBVxNT1ZxZQj-Mt3u-AZ5g=.c8d5d0d9-b5f9-4dbb-8661-c490882269be@github.com>

On Sun, 4 Jun 2023 18:47:13 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> JdbMethodExitTest.java tries to determine the jdb threadID for the "main" thread, and then later use it in jdb commands that require a threadID. It does this by first having the debuggee execute the following:
>> 
>> `        System.out.println("threadid="+Thread.currentThread().getId());`
>> 
>> And then later on the test parses the threadID from this output. The problem is that the id returned by getId() has no relation to threadIDs used by jdb, which are actually JDWP ObjectIDs. In the past this has worked due to some dumb luck. getID() always returns 1 for the main thread, which is always the thread we are executing in. Coincidentally the JDWP ObjectID for the main Thread object is also always 1 because this is the first ObjectID that the debug agent ever needs to create. However, when the debuggee main thread is a virtual thread, neither getId() nor JDWP assign 1 to the threadID, and in fact both will end up with very different values for the threadID. The end result is errors from jdb for using an invalid threadID.
>> 
>> The correct threadID can be obtained by executing the jdb "threads" command and parsing it from a line that looks like the following:
>> 
>> `   (java.lang.VirtualThread)694 main running (at breakpoint)`
>> 
>> Note this test will also fail due to [JDK-8309334](https://bugs.openjdk.org/browse/JDK-8309334), which should be fixed first. 
>> 
>> I've tested with mach5 tier5 in a workspace that has integrated the various CRs mentioned. Once JDK-8309334 is fixed, before integrating this PR I'll first merge and verify that the test being removed from the problem list by this PR also passes.
>
> Chris Plummer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - fix minor merge issue
>  - merge
>  - remove test from problem list
>  - properly determine the main threadId

Looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14294#pullrequestreview-1465846971

From duke at openjdk.org  Tue Jun  6 18:48:14 2023
From: duke at openjdk.org (Christine Flood)
Date: Tue, 6 Jun 2023 18:48:14 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v5]
In-Reply-To: <fcRlEmBBI3U8CovyR6Sp0qt49jlim5s6SdXAlpAx_tM=.a3102b4e-decd-4068-9cb5-8fa6fe6708f8@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <fcRlEmBBI3U8CovyR6Sp0qt49jlim5s6SdXAlpAx_tM=.a3102b4e-decd-4068-9cb5-8fa6fe6708f8@github.com>
Message-ID: <5kABzdo1H-Hs5ncz0KFnNH_9Ae0Z7hwPM8Qigg_0bjU=.b42d954e-5b69-4e77-82d8-217b6acb3e43@github.com>

On Sun, 4 Jun 2023 21:39:58 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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 three asserts making comparisons between atomic volatile variables
>   
>   Though changes to the volatile variables are individually protected by
>   Atomic load and store operations, these asserts were not assuring
>   atomic access to multiple volatile variables, each of which could be
>   modified independently of the others.  The asserts were therefore not
>   trustworthy, as has been confirmed by more extensive testing.

I wrote an LRU program back in 2017 which allocates trees and stores them in an array in a round robin fashion, freeing the last allocated.  At the time this was written it's purpose was to show how generational GCs can hit the wall and start performing very badly.  I ran this on a clean openjdk build, a genshen build in generational mode and a genshen  build in non-generational mode.   These results are repeatable for me. 

I would like to understand where the degradation is coming from before moving forward with this patch since it appears to penalize those who wish to just run traditional Shenandoah.

Clean
cflood at fedora java_programs]$ ~/genshen/cleanjdk/build/linux-x86_64-server-release/images/jdk/bin/java  -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC LRU 1000 1000
Took 341892ms to allocate 1000000 trees in a cache of 1000

Genshen generational (we expect this to be bad)
[cflood at fedora java_programs]$ ~/genshen/jdk/build/linux-x86_64-server-release/images/jdk/bin/java  -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational LRU 1000 1000
Took 442012ms to allocate 1000000 trees in a cache of 1000

Genshen non-generational (shows what I feel is a significant degradation from the clean build)
[cflood at fedora java_programs]$ ~/genshen/jdk/build/linux-x86_64-server-release/images/jdk/bin/java  -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC LRU 1000 1000
Took 395679ms to allocate 1000000 trees in a cache of 1000

I think that generational Shenandoah can be a big win for some applications, but I want to fully understand the cost for all applications.

I can't attach a .java file so here it is inline in the post.

class TreeNode {
    public TreeNode left, right;
    public int val;
}


public class LRU {
    static int cache_size;
    static int reps;
    static int tree_height=16;

    private static TreeNode[] trees;

    private static int getIndex(int i) {return i % cache_size;}
    private static TreeNode makeTree(int h) {
        if (h == 0) { return null;}
        else {
	    TreeNode res = new TreeNode();
	    res.left = makeTree(h - 1);
	    res.right = makeTree(h - 1);
	    res.val = h;
	    return res;
	}
    }

    public static void main(String[] args) {
        if (args.length != 2) {
            System.err.println("LRU requires args: cache_size reps");
            return;
        }
        cache_size = Integer.parseInt(args[0]);
        reps = Integer.parseInt(args[1]) * cache_size;
        trees = new TreeNode[cache_size];

        long start = System.currentTimeMillis();
        for (int i = 0; i < reps; i++)
            trees[getIndex(i)] = makeTree(tree_height);
        long end = System.currentTimeMillis();
        long ms = end - start;

        System.out.println("Took " + ms + "ms to allocate " + reps + " trees in a cache of " + cache_size);
    }
}

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

PR Comment: https://git.openjdk.org/jdk/pull/14185#issuecomment-1579278537

From sspitsyn at openjdk.org  Tue Jun  6 18:52:56 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 Jun 2023 18:52:56 GMT
Subject: RFR: 8309420: con/sun/jdi/StepTest.java fails with virtual thread
 wrapper
In-Reply-To: <av9ig1PwtvEjkgBDkNizeyzkLb4IDuEgMbv9ABq8vhs=.fac3313d-291f-4c81-914d-a67d14916911@github.com>
References: <av9ig1PwtvEjkgBDkNizeyzkLb4IDuEgMbv9ABq8vhs=.fac3313d-291f-4c81-914d-a67d14916911@github.com>
Message-ID: <g4UygCsWpxtsN7Fbdv3TQc0BkpEWvxiSRNkH_R1zo-c=.eba809d8-033e-4b90-affb-be0600130f1a@github.com>

On Mon, 5 Jun 2023 04:03:57 GMT, Chris Plummer <cjplummer at openjdk.org> 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.

Looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14307#pullrequestreview-1465860157

From phh at openjdk.org  Tue Jun  6 19:51:15 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Tue, 6 Jun 2023 19:51:15 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v5]
In-Reply-To: <fcRlEmBBI3U8CovyR6Sp0qt49jlim5s6SdXAlpAx_tM=.a3102b4e-decd-4068-9cb5-8fa6fe6708f8@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <fcRlEmBBI3U8CovyR6Sp0qt49jlim5s6SdXAlpAx_tM=.a3102b4e-decd-4068-9cb5-8fa6fe6708f8@github.com>
Message-ID: <K1Wskt39hvncoayo3T11IyzWcz3XepxVwlitpqOaN2E=.c39b472e-6ad2-4edd-b7ff-40b28d3d0b75@github.com>

On Sun, 4 Jun 2023 21:39:58 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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 three asserts making comparisons between atomic volatile variables
>   
>   Though changes to the volatile variables are individually protected by
>   Atomic load and store operations, these asserts were not assuring
>   atomic access to multiple volatile variables, each of which could be
>   modified independently of the others.  The asserts were therefore not
>   trustworthy, as has been confirmed by more extensive testing.

Thanks for finding the single-gen regression, we're very happy you took the time to run it and write up your results. We're very concerned about single-gen regressions too because we have single-gen Shen in production for several critical services.

We'd like to propose to push now, and tackle/fix the single-gen issue you identified during RDP1, as well as any other significant single-gen regressions that may come up. We have four Shen experts on board, Roman, Aleksey, Kelvin, and William, so believe it's doable before RDP2 in July. In the worst case that we fail, we'd emulate ZGC and move GenShen to it's own directory as an entirely separate collector before RDP2. Make sense?

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

PR Comment: https://git.openjdk.org/jdk/pull/14185#issuecomment-1579351993

From aph at openjdk.org  Tue Jun  6 19:59:13 2023
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 6 Jun 2023 19:59:13 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v5]
In-Reply-To: <fcRlEmBBI3U8CovyR6Sp0qt49jlim5s6SdXAlpAx_tM=.a3102b4e-decd-4068-9cb5-8fa6fe6708f8@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <fcRlEmBBI3U8CovyR6Sp0qt49jlim5s6SdXAlpAx_tM=.a3102b4e-decd-4068-9cb5-8fa6fe6708f8@github.com>
Message-ID: <uJcVz1fCLwV5-9NHogV_0JyFhn9HPL9x1y48AY0-43o=.b8ed66d5-4eeb-43bf-a7a7-0ee65de4401c@github.com>

On Sun, 4 Jun 2023 21:39:58 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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 three asserts making comparisons between atomic volatile variables
>   
>   Though changes to the volatile variables are individually protected by
>   Atomic load and store operations, these asserts were not assuring
>   atomic access to multiple volatile variables, each of which could be
>   modified independently of the others.  The asserts were therefore not
>   trustworthy, as has been confirmed by more extensive testing.

Marked as reviewed by aph (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14185#pullrequestreview-1465971078

From aph at openjdk.org  Tue Jun  6 19:59:14 2023
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 6 Jun 2023 19:59:14 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v5]
In-Reply-To: <K1Wskt39hvncoayo3T11IyzWcz3XepxVwlitpqOaN2E=.c39b472e-6ad2-4edd-b7ff-40b28d3d0b75@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <fcRlEmBBI3U8CovyR6Sp0qt49jlim5s6SdXAlpAx_tM=.a3102b4e-decd-4068-9cb5-8fa6fe6708f8@github.com>
 <K1Wskt39hvncoayo3T11IyzWcz3XepxVwlitpqOaN2E=.c39b472e-6ad2-4edd-b7ff-40b28d3d0b75@github.com>
Message-ID: <Ci8ACznHlFB_M1AQJcCmmx46MVJG08H0pQwQJ2mAfyw=.24ac3659-fac8-4a40-b016-fe650aaff1a0@github.com>

On Tue, 6 Jun 2023 19:48:05 GMT, Paul Hohensee <phh at openjdk.org> wrote:

> We'd like to propose to push now, and tackle/fix the single-gen issue you identified during RDP1, as well as any other significant single-gen regressions that may come up. We have four Shen experts on board, Roman, Aleksey, Kelvin, and William, so believe it's doable before RDP2 in July. In the worst case that we fail, we'd emulate ZGC and move GenShen to it's own directory as an entirely separate collector before RDP2. Make sense?

That sounds great to me. I'll approve this PR now, but please wait for Christine's ack.

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

PR Comment: https://git.openjdk.org/jdk/pull/14185#issuecomment-1579360356

From duke at openjdk.org  Tue Jun  6 20:04:22 2023
From: duke at openjdk.org (Christine Flood)
Date: Tue, 6 Jun 2023 20:04:22 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v5]
In-Reply-To: <fcRlEmBBI3U8CovyR6Sp0qt49jlim5s6SdXAlpAx_tM=.a3102b4e-decd-4068-9cb5-8fa6fe6708f8@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <fcRlEmBBI3U8CovyR6Sp0qt49jlim5s6SdXAlpAx_tM=.a3102b4e-decd-4068-9cb5-8fa6fe6708f8@github.com>
Message-ID: <7VPTUAp0zrlWrCGVgmWqkw5dXda3-1UPA8fcTEW6KoA=.9188218c-7216-4b74-b467-8dab75131578@github.com>

On Sun, 4 Jun 2023 21:39:58 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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 three asserts making comparisons between atomic volatile variables
>   
>   Though changes to the volatile variables are individually protected by
>   Atomic load and store operations, these asserts were not assuring
>   atomic access to multiple volatile variables, each of which could be
>   modified independently of the others.  The asserts were therefore not
>   trustworthy, as has been confirmed by more extensive testing.

This sounds good to me.

On Tue, Jun 6, 2023 at 3:55?PM Andrew Haley ***@***.***>
wrote:

> We'd like to propose to push now, and tackle/fix the single-gen issue you
> identified during RDP1, as well as any other significant single-gen
> regressions that may come up. We have four Shen experts on board, Roman,
> Aleksey, Kelvin, and William, so believe it's doable before RDP2 in July.
> In the worst case that we fail, we'd emulate ZGC and move GenShen to it's
> own directory as an entirely separate collector before RDP2. Make sense?
>
> That sounds great to me. I'll approve this PR now, but please wait for
> Christine's ack.
>
> ?
> Reply to this email directly, view it on GitHub
> <https://github.com/openjdk/jdk/pull/14185#issuecomment-1579360356>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AE3CLBA4HY42RUNTVPNBEADXJ6DMHANCNFSM6AAAAAAYQVSSLQ>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>

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

PR Comment: https://git.openjdk.org/jdk/pull/14185#issuecomment-1579367147

From cjplummer at openjdk.org  Tue Jun  6 20:07:33 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 6 Jun 2023 20:07:33 GMT
Subject: RFR: 8309396: com/sun/jdi/JdbMethodExitTest.java fails with
 virtual threads due to a bug in determining the main thread id [v3]
In-Reply-To: <_rWgi41CJ8newOTI2hqbjeNgOCCDTnNq030O6wXi_RI=.436a6404-306a-4001-b193-1206ee40f85d@github.com>
References: <_rWgi41CJ8newOTI2hqbjeNgOCCDTnNq030O6wXi_RI=.436a6404-306a-4001-b193-1206ee40f85d@github.com>
Message-ID: <-uk6ffen0XX1qSXW5KjuJqbAu0wBKdSHkej3npQiZ44=.ebff7c7e-c92e-4830-88e0-84f8cebbcec1@github.com>

> JdbMethodExitTest.java tries to determine the jdb threadID for the "main" thread, and then later use it in jdb commands that require a threadID. It does this by first having the debuggee execute the following:
> 
> `        System.out.println("threadid="+Thread.currentThread().getId());`
> 
> And then later on the test parses the threadID from this output. The problem is that the id returned by getId() has no relation to threadIDs used by jdb, which are actually JDWP ObjectIDs. In the past this has worked due to some dumb luck. getID() always returns 1 for the main thread, which is always the thread we are executing in. Coincidentally the JDWP ObjectID for the main Thread object is also always 1 because this is the first ObjectID that the debug agent ever needs to create. However, when the debuggee main thread is a virtual thread, neither getId() nor JDWP assign 1 to the threadID, and in fact both will end up with very different values for the threadID. The end result is errors from jdb for using an invalid threadID.
> 
> The correct threadID can be obtained by executing the jdb "threads" command and parsing it from a line that looks like the following:
> 
> `   (java.lang.VirtualThread)694 main running (at breakpoint)`
> 
> Note this test will also fail due to [JDK-8309334](https://bugs.openjdk.org/browse/JDK-8309334), which should be fixed first. 
> 
> I've tested with mach5 tier5 in a workspace that has integrated the various CRs mentioned. Once JDK-8309334 is fixed, before integrating this PR I'll first merge and verify that the test being removed from the problem list by this PR also passes.

Chris Plummer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge
 - fix minor merge issue
 - merge
 - remove test from problem list
 - properly determine the main threadId

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

Changes: https://git.openjdk.org/jdk/pull/14294/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14294&range=02
  Stats: 11 lines in 2 files changed: 5 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14294.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14294/head:pull/14294

PR: https://git.openjdk.org/jdk/pull/14294

From mr at openjdk.org  Tue Jun  6 20:19:12 2023
From: mr at openjdk.org (Mark Reinhold)
Date: Tue, 6 Jun 2023 20:19:12 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v5]
In-Reply-To: <7VPTUAp0zrlWrCGVgmWqkw5dXda3-1UPA8fcTEW6KoA=.9188218c-7216-4b74-b467-8dab75131578@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <fcRlEmBBI3U8CovyR6Sp0qt49jlim5s6SdXAlpAx_tM=.a3102b4e-decd-4068-9cb5-8fa6fe6708f8@github.com>
 <7VPTUAp0zrlWrCGVgmWqkw5dXda3-1UPA8fcTEW6KoA=.9188218c-7216-4b74-b467-8dab75131578@github.com>
Message-ID: <E2K-B_e5Ym5aZFrGMeIJkMrhbh_8MO4NRy6NGAz20zQ=.b75e8877-bde5-4a12-9341-0867b8f76b85@github.com>

On Tue, 6 Jun 2023 20:01:02 GMT, Christine Flood <duke at openjdk.org> wrote:

> We'd like to propose to push now, and tackle/fix the single-gen issue you identified during RDP1, as well as any other significant single-gen regressions that may come up. We have four Shen experts on board, Roman, Aleksey, Kelvin, and William, so believe it's doable before RDP2 in July. In the worst case that we fail, we'd emulate ZGC and move GenShen to it's own directory as an entirely separate collector before RDP2. Make sense?

Unsolicited advice: If you?re planning for this amount of change during RDP 1 then I?d say that you?re not ready for RDP 1.

If this patch were less isolated from the rest of HotSpot then I?d be extremely nervous.

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

PR Comment: https://git.openjdk.org/jdk/pull/14185#issuecomment-1579385819

From mdoerr at openjdk.org  Tue Jun  6 20:46:54 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 6 Jun 2023 20:46:54 GMT
Subject: RFR: JDK-8309462:
 vmTestbase/nsk/jvmti/RunAgentThread/agentthr001/TestDescription.java crashing
 due to empty while loop
In-Reply-To: <XLSnFyCggsHJL-YGgwO1icLhcDc-gFX98AR3NR8wB0Y=.024c3b61-79d2-42a6-a38e-517233c23091@github.com>
References: <XLSnFyCggsHJL-YGgwO1icLhcDc-gFX98AR3NR8wB0Y=.024c3b61-79d2-42a6-a38e-517233c23091@github.com>
Message-ID: <IKn5J7D1YNpjMYn3KyswRRdL61GBoSSKjCE-N1Nw8WQ=.f37a52e4-0b81-40e6-93c0-b62c62dc1eb5@github.com>

On Tue, 6 Jun 2023 09:51:09 GMT, JoKern65 <duke at openjdk.org> 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 <unistd.h>`
> `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) {`
> `     }`
> `}`

Changes requested by mdoerr (Reviewer).

test/hotspot/jtreg/vmTestbase/nsk/jvmti/RunAgentThread/agentthr001/agentthr001.cpp line 26:

> 24: #include <stdio.h>
> 25: #include <string.h>
> 26: #include <unistd.h>

Breaks Windows build: agentthr001.cpp(26): fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory

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

PR Review: https://git.openjdk.org/jdk/pull/14330#pullrequestreview-1466074354
PR Review Comment: https://git.openjdk.org/jdk/pull/14330#discussion_r1220327772

From phh at openjdk.org  Tue Jun  6 20:59:12 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Tue, 6 Jun 2023 20:59:12 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v5]
In-Reply-To: <fcRlEmBBI3U8CovyR6Sp0qt49jlim5s6SdXAlpAx_tM=.a3102b4e-decd-4068-9cb5-8fa6fe6708f8@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <fcRlEmBBI3U8CovyR6Sp0qt49jlim5s6SdXAlpAx_tM=.a3102b4e-decd-4068-9cb5-8fa6fe6708f8@github.com>
Message-ID: <3GigY7Hg2Clm2MqFsQnCWHxLB77_d-WM2c1kOi6wavA=.cc31a2e4-424d-48d1-9016-c409be4790c3@github.com>

On Sun, 4 Jun 2023 21:39:58 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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 three asserts making comparisons between atomic volatile variables
>   
>   Though changes to the volatile variables are individually protected by
>   Atomic load and store operations, these asserts were not assuring
>   atomic access to multiple volatile variables, each of which could be
>   modified independently of the others.  The asserts were therefore not
>   trustworthy, as has been confirmed by more extensive testing.

We understand, and would not have proposed the last chance split-directory alternative without the level of isolation Hotspot's GC interface enables. We've added single-gen performance enhancements on the way and would like to keep them!

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

PR Comment: https://git.openjdk.org/jdk/pull/14185#issuecomment-1579439750

From kdnilsen at openjdk.org  Tue Jun  6 21:12:41 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 6 Jun 2023 21:12:41 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v6]
In-Reply-To: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
Message-ID: <vdkbYfKE-wpjQiEVuSJdxfSDGQcloul63cXDWweGLIw=.26069f89-eced-4ffc-ba0f-98a99e05e309@github.com>

> 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 an inappropriate copyright notice

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14185/files
  - new: https://git.openjdk.org/jdk/pull/14185/files/8d80780a..9811d2aa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14185&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14185&range=04-05

  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

From cjplummer at openjdk.org  Tue Jun  6 21:15:55 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 6 Jun 2023 21:15:55 GMT
Subject: RFR: 8295976: GetThreadListStackTraces returns wrong state for
 blocked VirtualThread [v3]
In-Reply-To: <c2jVJSXHGbLFkSUCvqaU96NHE-UyF9vb6oATGM94I3k=.83797f52-90af-45e5-aea3-5ee20489e87b@github.com>
References: <_bbL6afkGfa1lw1UFa26F4lGRiLQaiIkjo0tkDMUHm4=.0079cdec-34c0-45f4-836f-61118c111f43@github.com>
 <c2jVJSXHGbLFkSUCvqaU96NHE-UyF9vb6oATGM94I3k=.83797f52-90af-45e5-aea3-5ee20489e87b@github.com>
Message-ID: <cwIWYK7tahSU_qyCLD2gmK1lfadRyS8X2rXYUxhiX7I=.9df7751d-2cb4-48ba-ab60-fdf93f572047@github.com>

On Tue, 6 Jun 2023 13:37:03 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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)
>
> Serguei Spitsyn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fixed typo in a comment in jvmtiEnvBase.cpp
>  - nit: restored one comment as was before

Changes requested by cjplummer (Reviewer).

test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java line 63:

> 61:     public void run() {
> 62:         log("TestTask.run()");
> 63:     }

I think this should be an abstract method.

test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java line 106:

> 104:         final Thread.State expState = Thread.State.WAITING;
> 105:         reentrantLock.lock();
> 106:         String name = "ObjectMonitorTestTask";

Should be "ReentrantLockTestTask"

test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest/libThreadListStackTracesTest.cpp line 35:

> 33: extern "C" {
> 34: 
> 35: JNIEXPORT jint JNICALL Java_ThreadListStackTracesTest_getStateSingle(JNIEnv* jni, jclass clazz, jthread vthread) {

I'd suggest splitting into 2 lines just like 
Java_ThreadListStackTracesTest_getStateMultiple() for the sake of consistency and being able to more easily compare the two.

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

PR Review: https://git.openjdk.org/jdk/pull/14326#pullrequestreview-1466112714
PR Review Comment: https://git.openjdk.org/jdk/pull/14326#discussion_r1220365810
PR Review Comment: https://git.openjdk.org/jdk/pull/14326#discussion_r1220367970
PR Review Comment: https://git.openjdk.org/jdk/pull/14326#discussion_r1220361274

From amenkov at openjdk.org  Tue Jun  6 21:25:56 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 6 Jun 2023 21:25:56 GMT
Subject: RFR: 8307153: JVMTI GetThreadState on carrier should return
 STATE_WAITING [v2]
In-Reply-To: <5-_kURDcYKd5WYKi9B331c8h6okVmGfvjdy_xqi1UqU=.012c360b-1b57-4773-b64b-d727dbf4daeb@github.com>
References: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>
 <5-_kURDcYKd5WYKi9B331c8h6okVmGfvjdy_xqi1UqU=.012c360b-1b57-4773-b64b-d727dbf4daeb@github.com>
Message-ID: <VFSEc0TtLF_BBzZ1NXDAFlGlm4dcvjqtsfsMiNVzumA=.7cd9f542-d592-42ef-8720-44115ac57fd6@github.com>

On Mon, 5 Jun 2023 19:00:49 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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 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 three additional commits since the last revision:
> 
>  - Merge
>  - minor tweaks in libThreadStateTest.cpp
>  - 8307153: JVMTI GetThreadState on carrier should return STATE_WAITING

src/hotspot/share/prims/jvmtiEnvBase.cpp line 764:

> 762: 
> 763:   if (is_passive_carrier_thread(jt, thread_oop)) {
> 764:     state |= (JVMTI_THREAD_STATE_WAITING | JVMTI_THREAD_STATE_WAITING_INDEFINITELY);

Not sure I understand this.
I'd expect 
`JVMTI_THREAD_STATE_ALIVE | JVMTI_THREAD_STATE_WAITING | JVMTI_THREAD_STATE_WAITING_INDEFINITELY` to be returned in the case.
How can a thread be JVMTI_THREAD_STATE_RUNNABLE and JVMTI_THREAD_STATE_WAITING at the same time?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14298#discussion_r1220384120

From sspitsyn at openjdk.org  Tue Jun  6 21:32:02 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 Jun 2023 21:32:02 GMT
Subject: RFR: 8295976: GetThreadListStackTraces returns wrong state for
 blocked VirtualThread [v3]
In-Reply-To: <cwIWYK7tahSU_qyCLD2gmK1lfadRyS8X2rXYUxhiX7I=.9df7751d-2cb4-48ba-ab60-fdf93f572047@github.com>
References: <_bbL6afkGfa1lw1UFa26F4lGRiLQaiIkjo0tkDMUHm4=.0079cdec-34c0-45f4-836f-61118c111f43@github.com>
 <c2jVJSXHGbLFkSUCvqaU96NHE-UyF9vb6oATGM94I3k=.83797f52-90af-45e5-aea3-5ee20489e87b@github.com>
 <cwIWYK7tahSU_qyCLD2gmK1lfadRyS8X2rXYUxhiX7I=.9df7751d-2cb4-48ba-ab60-fdf93f572047@github.com>
Message-ID: <KkVSlL2qIhjzzOj0W5xt0CI_2hO5bb0RAzex2hwzc7o=.e2dbb15c-f769-470c-94e7-face7fd1e699@github.com>

On Tue, 6 Jun 2023 21:07:46 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fixed typo in a comment in jvmtiEnvBase.cpp
>>  - nit: restored one comment as was before
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java line 63:
> 
>> 61:     public void run() {
>> 62:         log("TestTask.run()");
>> 63:     }
> 
> I think this should be an abstract method.

Thanks. Fixed now.

> test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java line 106:
> 
>> 104:         final Thread.State expState = Thread.State.WAITING;
>> 105:         reentrantLock.lock();
>> 106:         String name = "ObjectMonitorTestTask";
> 
> Should be "ReentrantLockTestTask"

Thanks. Fixed now.

> test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest/libThreadListStackTracesTest.cpp line 35:
> 
>> 33: extern "C" {
>> 34: 
>> 35: JNIEXPORT jint JNICALL Java_ThreadListStackTracesTest_getStateSingle(JNIEnv* jni, jclass clazz, jthread vthread) {
> 
> I'd suggest splitting into 2 lines just like 
> Java_ThreadListStackTracesTest_getStateMultiple() for the sake of consistency and being able to more easily compare the two.

Thanks. I've overlooked this. Fixed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14326#discussion_r1220390676
PR Review Comment: https://git.openjdk.org/jdk/pull/14326#discussion_r1220392423
PR Review Comment: https://git.openjdk.org/jdk/pull/14326#discussion_r1220387806

From kdnilsen at openjdk.org  Tue Jun  6 21:36:44 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 6 Jun 2023 21:36:44 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v7]
In-Reply-To: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
Message-ID: <j9WF3CL0XVKxN08izsW-sSsuuv09Mjh3X-rBcS8dT98=.d8822b4f-b935-4010-8a30-4135c8d233c6@github.com>

> 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:

  Exit during initialization on unsupported platforms

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14185/files
  - new: https://git.openjdk.org/jdk/pull/14185/files/9811d2aa..cc149904

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14185&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14185&range=05-06

  Stats: 4 lines in 1 file changed: 4 ins; 0 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

From sspitsyn at openjdk.org  Tue Jun  6 21:37:25 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 Jun 2023 21:37:25 GMT
Subject: RFR: 8295976: GetThreadListStackTraces returns wrong state for
 blocked VirtualThread [v4]
In-Reply-To: <_bbL6afkGfa1lw1UFa26F4lGRiLQaiIkjo0tkDMUHm4=.0079cdec-34c0-45f4-836f-61118c111f43@github.com>
References: <_bbL6afkGfa1lw1UFa26F4lGRiLQaiIkjo0tkDMUHm4=.0079cdec-34c0-45f4-836f-61118c111f43@github.com>
Message-ID: <nq7fHcvhDEfARPKMBm1Pi7D6ETYIJuhr8_qQT7J5A54=.bb1e8e3e-a84a-4adf-a176-2f4ef16c2968@github.com>

> 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)

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  addressed new test related review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14326/files
  - new: https://git.openjdk.org/jdk/pull/14326/files/d20e1221..e982f97e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14326&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14326&range=02-03

  Stats: 6 lines in 2 files changed: 1 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14326.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14326/head:pull/14326

PR: https://git.openjdk.org/jdk/pull/14326

From kdnilsen at openjdk.org  Tue Jun  6 21:46:12 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 6 Jun 2023 21:46:12 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v7]
In-Reply-To: <WuVIRjQQhANFoCsiipvCQd4wvKqSyMuYi5kuCA9dv70=.7f94f9a4-5653-4214-b411-9b32f58c7ed3@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <WuVIRjQQhANFoCsiipvCQd4wvKqSyMuYi5kuCA9dv70=.7f94f9a4-5653-4214-b411-9b32f58c7ed3@github.com>
Message-ID: <lYnNXjCwMF-VoOfnUz3bfFmS4G9sdijBQK7zAyKdWdE=.5210d0a7-3815-409f-b04e-5f68e51cfbee@github.com>

On Thu, 1 Jun 2023 13:32:49 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Exit during initialization on unsupported platforms
>
> test/hotspot/jtreg/gc/shenandoah/TestEvilSyncBug.java line 33:
> 
>> 31:  * @modules java.base/jdk.internal.misc
>> 32:  *          java.management
>> 33:  * @run driver/timeout=480 TestEvilSyncBug -XX:ShenandoahGCHeuristics=aggressive
> 
> Probably fine, but why this change to non-generational testing? Will aggressive heuristic sharpen the test?

We moved this argument from the source code (original line 64) to here so that we can invoke the test differently in generational mode.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1220410522

From cjplummer at openjdk.org  Tue Jun  6 21:50:55 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 6 Jun 2023 21:50:55 GMT
Subject: RFR: 8295976: GetThreadListStackTraces returns wrong state for
 blocked VirtualThread [v4]
In-Reply-To: <nq7fHcvhDEfARPKMBm1Pi7D6ETYIJuhr8_qQT7J5A54=.bb1e8e3e-a84a-4adf-a176-2f4ef16c2968@github.com>
References: <_bbL6afkGfa1lw1UFa26F4lGRiLQaiIkjo0tkDMUHm4=.0079cdec-34c0-45f4-836f-61118c111f43@github.com>
 <nq7fHcvhDEfARPKMBm1Pi7D6ETYIJuhr8_qQT7J5A54=.bb1e8e3e-a84a-4adf-a176-2f4ef16c2968@github.com>
Message-ID: <14FIsTgic9d0rLeA9rAVsfPlBdWnyQkvXKGnYg2j9to=.f5e31a08-e29b-4e3a-ba44-15206f05ff83@github.com>

On Tue, 6 Jun 2023 21:37:25 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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)
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressed new test related review comments

Looks good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14326#pullrequestreview-1466172053

From clanger at openjdk.org  Tue Jun  6 21:53:56 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 6 Jun 2023 21:53:56 GMT
Subject: RFR: JDK-8309462:
 vmTestbase/nsk/jvmti/RunAgentThread/agentthr001/TestDescription.java crashing
 due to empty while loop
In-Reply-To: <XLSnFyCggsHJL-YGgwO1icLhcDc-gFX98AR3NR8wB0Y=.024c3b61-79d2-42a6-a38e-517233c23091@github.com>
References: <XLSnFyCggsHJL-YGgwO1icLhcDc-gFX98AR3NR8wB0Y=.024c3b61-79d2-42a6-a38e-517233c23091@github.com>
Message-ID: <365iru-S_oNYKt8H6TCLjXeguy6o3-jWEEvCVS7r2GQ=.e80fa994-ba93-469f-a73d-0a5f9489f504@github.com>

On Tue, 6 Jun 2023 09:51:09 GMT, JoKern65 <duke at openjdk.org> 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 <unistd.h>`
> `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) {`
> `     }`
> `}`

The solution to use sleep looks fine. Please address the comments and also update the copyright year.

test/hotspot/jtreg/vmTestbase/nsk/jvmti/RunAgentThread/agentthr001/agentthr001.cpp line 141:

> 139: sys_thread_3(jvmtiEnv* jvmti, JNIEnv* jni, void *p) {
> 140:     while (1) {
> 141:       sleep(1);

Maybe you could add a comment here that the call to sleep is necessary to avoid the compiler optimization to elide the loop.

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

Changes requested by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14330#pullrequestreview-1466167108
PR Review Comment: https://git.openjdk.org/jdk/pull/14330#discussion_r1220417459

From clanger at openjdk.org  Tue Jun  6 21:54:00 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 6 Jun 2023 21:54:00 GMT
Subject: RFR: JDK-8309462:
 vmTestbase/nsk/jvmti/RunAgentThread/agentthr001/TestDescription.java crashing
 due to empty while loop
In-Reply-To: <IKn5J7D1YNpjMYn3KyswRRdL61GBoSSKjCE-N1Nw8WQ=.f37a52e4-0b81-40e6-93c0-b62c62dc1eb5@github.com>
References: <XLSnFyCggsHJL-YGgwO1icLhcDc-gFX98AR3NR8wB0Y=.024c3b61-79d2-42a6-a38e-517233c23091@github.com>
 <IKn5J7D1YNpjMYn3KyswRRdL61GBoSSKjCE-N1Nw8WQ=.f37a52e4-0b81-40e6-93c0-b62c62dc1eb5@github.com>
Message-ID: <tBBsJsiPIoGUeu1xyikPrbkDbz9auCT2PJBNNyhgY7Y=.20c3259f-9b4e-4af0-9ae6-7bbc02017588@github.com>

On Tue, 6 Jun 2023 20:43:36 GMT, Martin Doerr <mdoerr at openjdk.org> 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 <unistd.h>`
>> `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) {`
>> `     }`
>> `}`
>
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/RunAgentThread/agentthr001/agentthr001.cpp line 26:
> 
>> 24: #include <stdio.h>
>> 25: #include <string.h>
>> 26: #include <unistd.h>
> 
> Breaks Windows build: agentthr001.cpp(26): fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory

On Windows I think you need windows.h. I guess you can do it like here: https://github.com/openjdk/jdk/blob/4a75fd462c002a209201d8bfc8d6c9eb286a7444/src/java.base/share/native/libjli/wildcard.c#L99

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14330#discussion_r1220410431

From kdnilsen at openjdk.org  Tue Jun  6 21:54:14 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 6 Jun 2023 21:54:14 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v7]
In-Reply-To: <lYnNXjCwMF-VoOfnUz3bfFmS4G9sdijBQK7zAyKdWdE=.5210d0a7-3815-409f-b04e-5f68e51cfbee@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <WuVIRjQQhANFoCsiipvCQd4wvKqSyMuYi5kuCA9dv70=.7f94f9a4-5653-4214-b411-9b32f58c7ed3@github.com>
 <lYnNXjCwMF-VoOfnUz3bfFmS4G9sdijBQK7zAyKdWdE=.5210d0a7-3815-409f-b04e-5f68e51cfbee@github.com>
Message-ID: <KrNTiwSEF8znahSnCEQz9iUYtX1kY7sSXnhxLMlylfc=.8c1e999b-dafe-4c64-b7c5-254daa2ebd68@github.com>

On Tue, 6 Jun 2023 21:43:36 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> test/hotspot/jtreg/gc/shenandoah/TestEvilSyncBug.java line 33:
>> 
>>> 31:  * @modules java.base/jdk.internal.misc
>>> 32:  *          java.management
>>> 33:  * @run driver/timeout=480 TestEvilSyncBug -XX:ShenandoahGCHeuristics=aggressive
>> 
>> Probably fine, but why this change to non-generational testing? Will aggressive heuristic sharpen the test?
>
> We moved this argument from the source code (original line 64) to here so that we can invoke the test differently in generational mode.

See line 64 of the original source code.  We did not change the behavior.  We only changed how the behavior is realized.  This enables generalization of the test to generational mode.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1220418431

From kdnilsen at openjdk.org  Tue Jun  6 21:54:16 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 6 Jun 2023 21:54:16 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v7]
In-Reply-To: <WuVIRjQQhANFoCsiipvCQd4wvKqSyMuYi5kuCA9dv70=.7f94f9a4-5653-4214-b411-9b32f58c7ed3@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <WuVIRjQQhANFoCsiipvCQd4wvKqSyMuYi5kuCA9dv70=.7f94f9a4-5653-4214-b411-9b32f58c7ed3@github.com>
Message-ID: <Zeo844jM9pNVxkwXeFFbF9zzXiCa2gv4WHUcGpnYkKM=.eae7bac0-b0e9-457f-aed2-51371800f276@github.com>

On Thu, 1 Jun 2023 14:25:19 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Exit during initialization on unsupported platforms
>
> test/hotspot/jtreg/gc/shenandoah/oom/TestAllocOutOfMemory.java line 92:
> 
>> 90:             expectFailure("-Xmx16m",
>> 91:                           "-XX:+UnlockExperimentalVMOptions",
>> 92:                           "-XX:+UseShenandoahGC",
> 
> Nit: should not need UnlockExperimentalVMOptions anymore.

We actually do need to UnlockExperimentalVMOptions because generational mode is currently an experimental feature.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1220417069

From clanger at openjdk.org  Tue Jun  6 21:57:55 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 6 Jun 2023 21:57:55 GMT
Subject: RFR: JDK-8309225: Fix xlc17 clang 15 warnings in security and
 servicability
In-Reply-To: <TVjM9BfpfntsYda5nA4AcZazR-O8Mjl1SyTFu-Bmtpo=.d407a6a1-a865-49ea-8a58-deba1ba11d0c@github.com>
References: <TVjM9BfpfntsYda5nA4AcZazR-O8Mjl1SyTFu-Bmtpo=.d407a6a1-a865-49ea-8a58-deba1ba11d0c@github.com>
Message-ID: <IfO5y4LIG-GVWjGXyWJHoqmEaU6dMN7llooxh8YhlQ4=.c39ce1bb-c635-4029-81ac-ac6937cd8c5d@github.com>

On Fri, 2 Jun 2023 10:19:53 GMT, JoKern65 <duke at openjdk.org> 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}

Marked as reviewed by clanger (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14282#pullrequestreview-1466180987

From cjplummer at openjdk.org  Tue Jun  6 22:00:05 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 6 Jun 2023 22:00:05 GMT
Subject: RFR: 8309396: com/sun/jdi/JdbMethodExitTest.java fails with
 virtual threads due to a bug in determining the main thread id [v3]
In-Reply-To: <-uk6ffen0XX1qSXW5KjuJqbAu0wBKdSHkej3npQiZ44=.ebff7c7e-c92e-4830-88e0-84f8cebbcec1@github.com>
References: <_rWgi41CJ8newOTI2hqbjeNgOCCDTnNq030O6wXi_RI=.436a6404-306a-4001-b193-1206ee40f85d@github.com>
 <-uk6ffen0XX1qSXW5KjuJqbAu0wBKdSHkej3npQiZ44=.ebff7c7e-c92e-4830-88e0-84f8cebbcec1@github.com>
Message-ID: <4okHmqxNLArxtH8q6yeSYG-U4vX9RIkRQV6UCydUBAI=.87e6ab7e-c5d4-4bd5-9ace-34268f6dd4a7@github.com>

On Tue, 6 Jun 2023 20:07:33 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> JdbMethodExitTest.java tries to determine the jdb threadID for the "main" thread, and then later use it in jdb commands that require a threadID. It does this by first having the debuggee execute the following:
>> 
>> `        System.out.println("threadid="+Thread.currentThread().getId());`
>> 
>> And then later on the test parses the threadID from this output. The problem is that the id returned by getId() has no relation to threadIDs used by jdb, which are actually JDWP ObjectIDs. In the past this has worked due to some dumb luck. getID() always returns 1 for the main thread, which is always the thread we are executing in. Coincidentally the JDWP ObjectID for the main Thread object is also always 1 because this is the first ObjectID that the debug agent ever needs to create. However, when the debuggee main thread is a virtual thread, neither getId() nor JDWP assign 1 to the threadID, and in fact both will end up with very different values for the threadID. The end result is errors from jdb for using an invalid threadID.
>> 
>> The correct threadID can be obtained by executing the jdb "threads" command and parsing it from a line that looks like the following:
>> 
>> `   (java.lang.VirtualThread)694 main running (at breakpoint)`
>> 
>> Note this test will also fail due to [JDK-8309334](https://bugs.openjdk.org/browse/JDK-8309334), which should be fixed first. 
>> 
>> I've tested with mach5 tier5 in a workspace that has integrated the various CRs mentioned. Once JDK-8309334 is fixed, before integrating this PR I'll first merge and verify that the test being removed from the problem list by this PR also passes.
>
> Chris Plummer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge
>  - fix minor merge issue
>  - merge
>  - remove test from problem list
>  - properly determine the main threadId

Thanks for the reviews Alex and Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/14294#issuecomment-1579501697

From cjplummer at openjdk.org  Tue Jun  6 22:00:07 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 6 Jun 2023 22:00:07 GMT
Subject: Integrated: 8309396: com/sun/jdi/JdbMethodExitTest.java fails with
 virtual threads due to a bug in determining the main thread id
In-Reply-To: <_rWgi41CJ8newOTI2hqbjeNgOCCDTnNq030O6wXi_RI=.436a6404-306a-4001-b193-1206ee40f85d@github.com>
References: <_rWgi41CJ8newOTI2hqbjeNgOCCDTnNq030O6wXi_RI=.436a6404-306a-4001-b193-1206ee40f85d@github.com>
Message-ID: <h-05Ecg0WQfzwuJCvZu_3Lkqo9Ubcbo_tKdO0VxCoyc=.88146b2a-6032-4ad4-8bcc-c9231d14b5dd@github.com>

On Fri, 2 Jun 2023 21:47:47 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> JdbMethodExitTest.java tries to determine the jdb threadID for the "main" thread, and then later use it in jdb commands that require a threadID. It does this by first having the debuggee execute the following:
> 
> `        System.out.println("threadid="+Thread.currentThread().getId());`
> 
> And then later on the test parses the threadID from this output. The problem is that the id returned by getId() has no relation to threadIDs used by jdb, which are actually JDWP ObjectIDs. In the past this has worked due to some dumb luck. getID() always returns 1 for the main thread, which is always the thread we are executing in. Coincidentally the JDWP ObjectID for the main Thread object is also always 1 because this is the first ObjectID that the debug agent ever needs to create. However, when the debuggee main thread is a virtual thread, neither getId() nor JDWP assign 1 to the threadID, and in fact both will end up with very different values for the threadID. The end result is errors from jdb for using an invalid threadID.
> 
> The correct threadID can be obtained by executing the jdb "threads" command and parsing it from a line that looks like the following:
> 
> `   (java.lang.VirtualThread)694 main running (at breakpoint)`
> 
> Note this test will also fail due to [JDK-8309334](https://bugs.openjdk.org/browse/JDK-8309334), which should be fixed first. 
> 
> I've tested with mach5 tier5 in a workspace that has integrated the various CRs mentioned. Once JDK-8309334 is fixed, before integrating this PR I'll first merge and verify that the test being removed from the problem list by this PR also passes.

This pull request has now been integrated.

Changeset: 65bdbc7a
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/65bdbc7a8c06e5f119c9db832734664780933e01
Stats:     11 lines in 2 files changed: 5 ins; 2 del; 4 mod

8309396: com/sun/jdi/JdbMethodExitTest.java fails with virtual threads due to a bug in determining the main thread id

Reviewed-by: amenkov, sspitsyn

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

PR: https://git.openjdk.org/jdk/pull/14294

From sspitsyn at openjdk.org  Tue Jun  6 22:07:14 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 Jun 2023 22:07:14 GMT
Subject: RFR: 8307153: JVMTI GetThreadState on carrier should return
 STATE_WAITING [v3]
In-Reply-To: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>
References: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>
Message-ID: <o6yP-hMjjhjGriZSbQ-JiLJebJ1G1FohkZFk7dIMYa4=.2c4c4195-83af-4e7b-b421-01054df6e74c@github.com>

> 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: removed JVMTI_THREAD_STATE_RUNNABLE from a carrier thread state

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14298/files
  - new: https://git.openjdk.org/jdk/pull/14298/files/e60da02e..b5eb3835

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14298&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14298&range=01-02

  Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 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

From sspitsyn at openjdk.org  Tue Jun  6 22:07:18 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 Jun 2023 22:07:18 GMT
Subject: RFR: 8307153: JVMTI GetThreadState on carrier should return
 STATE_WAITING [v2]
In-Reply-To: <VFSEc0TtLF_BBzZ1NXDAFlGlm4dcvjqtsfsMiNVzumA=.7cd9f542-d592-42ef-8720-44115ac57fd6@github.com>
References: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>
 <5-_kURDcYKd5WYKi9B331c8h6okVmGfvjdy_xqi1UqU=.012c360b-1b57-4773-b64b-d727dbf4daeb@github.com>
 <VFSEc0TtLF_BBzZ1NXDAFlGlm4dcvjqtsfsMiNVzumA=.7cd9f542-d592-42ef-8720-44115ac57fd6@github.com>
Message-ID: <eOcnix7D1HicpkX2R0F71Ph8ZipNfsLDzyeeMO9t6nQ=.f1555743-25a5-4715-a55c-f90db4accaad@github.com>

On Tue, 6 Jun 2023 21:22:40 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> 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 three additional commits since the last revision:
>> 
>>  - Merge
>>  - minor tweaks in libThreadStateTest.cpp
>>  - 8307153: JVMTI GetThreadState on carrier should return STATE_WAITING
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 764:
> 
>> 762: 
>> 763:   if (is_passive_carrier_thread(jt, thread_oop)) {
>> 764:     state |= (JVMTI_THREAD_STATE_WAITING | JVMTI_THREAD_STATE_WAITING_INDEFINITELY);
> 
> Not sure I understand this.
> I'd expect 
> `JVMTI_THREAD_STATE_ALIVE | JVMTI_THREAD_STATE_WAITING | JVMTI_THREAD_STATE_WAITING_INDEFINITELY` to be returned in the case.
> How can a thread be JVMTI_THREAD_STATE_RUNNABLE and JVMTI_THREAD_STATE_WAITING at the same time?

Good catch, thanks. Fixed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14298#discussion_r1220428448

From sspitsyn at openjdk.org  Tue Jun  6 22:09:54 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 Jun 2023 22:09:54 GMT
Subject: RFR: 8307153: JVMTI GetThreadState on carrier should return
 STATE_WAITING [v3]
In-Reply-To: <jRansukCg6_vwIh6V_bBvJu52yCBeczPELl4KEaKxmA=.61870be5-8131-46b8-ad93-e123e9027dff@github.com>
References: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>
 <SH2pr7y0t3C1v3EFDfgS4AArNAxNXbb1LTPC6xrKGI8=.2a629523-a681-4b61-988f-4df5e60e7a2b@github.com>
 <t-iQRZCgi0Jv6fpJDBRLID3Bhll-2ezYbVHfC7u79N0=.4db46ff4-351e-4737-81fb-b66ebb4358ed@github.com>
 <MkJ9Qmy6wtW_uzB2VXyFbfMujlzTgF_Tc_DM6n0z9HU=.de134484-9fa3-4ac9-a68f-5a2b3b5be59c@github.com>
 <chf9KOskdhm96pUVVgA9gIS2aPHPTnHQ3cAAjDRYJV4=.331b1bdd-3dc5-4f4a-ba15-9514f8b39ee6@github.com>
 <jRansukCg6_vwIh6V_bBvJu52yCBeczPELl4KEaKxmA=.61870be5-8131-46b8-ad93-e123e9027dff@github.com>
Message-ID: <GRu9lEuu6sVCRKbqaOniXipjdYQVSisid8Fu2eyZJEM=.45f6731c-8df6-4734-9e24-65b226e95ce7@github.com>

On Tue, 6 Jun 2023 15:43:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Okay, I see you point. Unfortunately, I've always referred the platform thread with an executed FJP schedular as a carrier thread. The term 'carrier' with this meaning is everywhere in the JVMTI code. It looks very confusing to call a thread to be a carrier thread only during some phases of its execution.
>
>> Okay, I see you point. Unfortunately, I've always referred the platform thread with an executed FJP schedular as a carrier thread. The term 'carrier' with this meaning is everywhere in the JVMTI code. It looks very confusing to call a thread to be a carrier thread only during some phases of its execution.
> 
> Okay, I'm just pointing out that is_passive_carrier_thread looks a bit strange here as it is testing if a JavaThread is carrying a virtual thread oop -  it's not testing if the thread is owned by the virtual thread scheduler.

I'm still thinking what identifier to use instead of `is_passive_carrier_thread`.
Just `is_carrier_thread` is going to be confusing as well.
What about `is_carrier_thread_waiting_for_virtual` or `is_carrier_thread_waiting_for_virtual_to_unmount`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14298#discussion_r1220435738

From amenkov at openjdk.org  Tue Jun  6 22:20:59 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 6 Jun 2023 22:20:59 GMT
Subject: RFR: 8307153: JVMTI GetThreadState on carrier should return
 STATE_WAITING [v3]
In-Reply-To: <o6yP-hMjjhjGriZSbQ-JiLJebJ1G1FohkZFk7dIMYa4=.2c4c4195-83af-4e7b-b421-01054df6e74c@github.com>
References: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>
 <o6yP-hMjjhjGriZSbQ-JiLJebJ1G1FohkZFk7dIMYa4=.2c4c4195-83af-4e7b-b421-01054df6e74c@github.com>
Message-ID: <96WXnBOucA3CuQDIfxYFBKhHC1_Uo651LphuRFeLgcI=.6cd798f1-2849-4871-94e3-ab9df30f393d@github.com>

On Tue, 6 Jun 2023 22:07:14 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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: removed JVMTI_THREAD_STATE_RUNNABLE from a carrier thread state

src/hotspot/share/prims/jvmtiEnvBase.cpp line 768:

> 766:   }
> 767:   return state;
> 768: }

You don't need to call get_thread_state_base in case "passive carrier thread":

    if (is_passive_carrier_thread(jt, thread_oop)) {
      return JVMTI_THREAD_STATE_ALIVE | JVMTI_THREAD_STATE_WAITING
             | JVMTI_THREAD_STATE_WAITING_INDEFINITELY;
    }
    return get_thread_state_base(thread_oop, jt);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14298#discussion_r1220447606

From amenkov at openjdk.org  Tue Jun  6 22:39:09 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 6 Jun 2023 22:39:09 GMT
Subject: RFR: 8295976: GetThreadListStackTraces returns wrong state for
 blocked VirtualThread [v4]
In-Reply-To: <nq7fHcvhDEfARPKMBm1Pi7D6ETYIJuhr8_qQT7J5A54=.bb1e8e3e-a84a-4adf-a176-2f4ef16c2968@github.com>
References: <_bbL6afkGfa1lw1UFa26F4lGRiLQaiIkjo0tkDMUHm4=.0079cdec-34c0-45f4-836f-61118c111f43@github.com>
 <nq7fHcvhDEfARPKMBm1Pi7D6ETYIJuhr8_qQT7J5A54=.bb1e8e3e-a84a-4adf-a176-2f4ef16c2968@github.com>
Message-ID: <7-6AydLkwjCOkTHA2sI-f7axGSMpCq5havZC5K6qz5U=.93d29276-ab0e-444e-b22c-d4b5f1c9b68b@github.com>

On Tue, 6 Jun 2023 21:37:25 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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)
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressed new test related review comments

Marked as reviewed by amenkov (Reviewer).

test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java line 29:

> 27:  * @summary GetThreadListStackTraces returns wrong state for blocked VirtualThread
> 28:  * @requires vm.continuations
> 29:  * @modules java.base/java.lang:+open

I think `@modules` it's not needed

test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java line 34:

> 32: 
> 33: import java.util.concurrent.locks.ReentrantLock;
> 34: import java.util.concurrent.*;

unused imports

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

PR Review: https://git.openjdk.org/jdk/pull/14326#pullrequestreview-1466246664
PR Review Comment: https://git.openjdk.org/jdk/pull/14326#discussion_r1220481289
PR Review Comment: https://git.openjdk.org/jdk/pull/14326#discussion_r1220480268

From sspitsyn at openjdk.org  Tue Jun  6 22:41:54 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 Jun 2023 22:41:54 GMT
Subject: RFR: 8307153: JVMTI GetThreadState on carrier should return
 STATE_WAITING [v4]
In-Reply-To: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>
References: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>
Message-ID: <UUIMk0DSyDCcAPQPQjFIZr4SLLMFn2TKx-bxYl2xPAA=.25db26ee-97a4-48bd-965c-3c90868b51df@github.com>

> 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: call get_thread_state_base only when needed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14298/files
  - new: https://git.openjdk.org/jdk/pull/14298/files/b5eb3835..77771816

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14298&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14298&range=02-03

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 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

From amenkov at openjdk.org  Tue Jun  6 22:41:57 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 6 Jun 2023 22:41:57 GMT
Subject: RFR: 8309510:
 com/sun/jdi/RedefineNestmateAttr/TestNestmateAttr.java no longer needs to
 override startup() method
In-Reply-To: <6kWHttu7fg50M_7FJ_zGVAbJl-UrWu6VfPMwyFCEUUk=.d6e1fcea-f821-4adb-92f4-217051c572e7@github.com>
References: <6kWHttu7fg50M_7FJ_zGVAbJl-UrWu6VfPMwyFCEUUk=.d6e1fcea-f821-4adb-92f4-217051c572e7@github.com>
Message-ID: <Qhu7z3MlpSMZYO-zYgS8jTX6qnWuyaLc4i_WOmtspyg=.af1eaea3-140e-4ef1-981a-6f2bba84912d@github.com>

On Tue, 6 Jun 2023 00:36:12 GMT, Chris Plummer <cjplummer at openjdk.org> 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<String> 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.

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14325#pullrequestreview-1466250289

From sspitsyn at openjdk.org  Tue Jun  6 22:41:58 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 Jun 2023 22:41:58 GMT
Subject: RFR: 8307153: JVMTI GetThreadState on carrier should return
 STATE_WAITING [v3]
In-Reply-To: <96WXnBOucA3CuQDIfxYFBKhHC1_Uo651LphuRFeLgcI=.6cd798f1-2849-4871-94e3-ab9df30f393d@github.com>
References: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>
 <o6yP-hMjjhjGriZSbQ-JiLJebJ1G1FohkZFk7dIMYa4=.2c4c4195-83af-4e7b-b421-01054df6e74c@github.com>
 <96WXnBOucA3CuQDIfxYFBKhHC1_Uo651LphuRFeLgcI=.6cd798f1-2849-4871-94e3-ab9df30f393d@github.com>
Message-ID: <hd2Q3bmJZmqJVeXrCUiJvGp-hjZfTV0PvLu1SJbpKEU=.8cf4cb76-df5b-4df2-bfc5-32ceac3bd4c5@github.com>

On Tue, 6 Jun 2023 22:17:57 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: removed JVMTI_THREAD_STATE_RUNNABLE from a carrier thread state
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 768:
> 
>> 766:   }
>> 767:   return state;
>> 768: }
> 
> You don't need to call get_thread_state_base in case "passive carrier thread":
> 
>     if (is_passive_carrier_thread(jt, thread_oop)) {
>       return JVMTI_THREAD_STATE_ALIVE | JVMTI_THREAD_STATE_WAITING
>              | JVMTI_THREAD_STATE_WAITING_INDEFINITELY;
>     }
>     return get_thread_state_base(thread_oop, jt);

Thanks. Yes, noticed it. :) Fixed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14298#discussion_r1220484149

From sspitsyn at openjdk.org  Tue Jun  6 22:54:04 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 Jun 2023 22:54:04 GMT
Subject: RFR: 8295976: GetThreadListStackTraces returns wrong state for
 blocked VirtualThread [v5]
In-Reply-To: <_bbL6afkGfa1lw1UFa26F4lGRiLQaiIkjo0tkDMUHm4=.0079cdec-34c0-45f4-836f-61118c111f43@github.com>
References: <_bbL6afkGfa1lw1UFa26F4lGRiLQaiIkjo0tkDMUHm4=.0079cdec-34c0-45f4-836f-61118c111f43@github.com>
Message-ID: <k8uygjjp4f42IN5Q4yeDOzGRTUEoh5DJg_s91r5lgwM=.d23c5ab3-8d02-4f2b-8c51-d6e2459d1f12@github.com>

> 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)

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: ThreadListStackTracesTest cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14326/files
  - new: https://git.openjdk.org/jdk/pull/14326/files/e982f97e..6b685ca3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14326&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14326&range=03-04

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14326.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14326/head:pull/14326

PR: https://git.openjdk.org/jdk/pull/14326

From sspitsyn at openjdk.org  Tue Jun  6 22:54:06 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 Jun 2023 22:54:06 GMT
Subject: RFR: 8295976: GetThreadListStackTraces returns wrong state for
 blocked VirtualThread [v4]
In-Reply-To: <nq7fHcvhDEfARPKMBm1Pi7D6ETYIJuhr8_qQT7J5A54=.bb1e8e3e-a84a-4adf-a176-2f4ef16c2968@github.com>
References: <_bbL6afkGfa1lw1UFa26F4lGRiLQaiIkjo0tkDMUHm4=.0079cdec-34c0-45f4-836f-61118c111f43@github.com>
 <nq7fHcvhDEfARPKMBm1Pi7D6ETYIJuhr8_qQT7J5A54=.bb1e8e3e-a84a-4adf-a176-2f4ef16c2968@github.com>
Message-ID: <0U4aaMnv803nuwN5lempsD-eUFIEiC6WbQr0lCnwTKo=.6b13a626-79ff-4968-ae05-6da81ed5e997@github.com>

On Tue, 6 Jun 2023 21:37:25 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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)
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressed new test related review comments

Chris and Alex, thank you for review!

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

PR Comment: https://git.openjdk.org/jdk/pull/14326#issuecomment-1579560041

From sspitsyn at openjdk.org  Tue Jun  6 22:54:07 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 Jun 2023 22:54:07 GMT
Subject: RFR: 8295976: GetThreadListStackTraces returns wrong state for
 blocked VirtualThread [v4]
In-Reply-To: <7-6AydLkwjCOkTHA2sI-f7axGSMpCq5havZC5K6qz5U=.93d29276-ab0e-444e-b22c-d4b5f1c9b68b@github.com>
References: <_bbL6afkGfa1lw1UFa26F4lGRiLQaiIkjo0tkDMUHm4=.0079cdec-34c0-45f4-836f-61118c111f43@github.com>
 <nq7fHcvhDEfARPKMBm1Pi7D6ETYIJuhr8_qQT7J5A54=.bb1e8e3e-a84a-4adf-a176-2f4ef16c2968@github.com>
 <7-6AydLkwjCOkTHA2sI-f7axGSMpCq5havZC5K6qz5U=.93d29276-ab0e-444e-b22c-d4b5f1c9b68b@github.com>
Message-ID: <bc6mRINLiCmfhP7G2ckx0MlPoW904l6nQXAdgBMvPJk=.065e0b59-f952-4637-a3d7-76710018745a@github.com>

On Tue, 6 Jun 2023 22:34:33 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   addressed new test related review comments
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java line 29:
> 
>> 27:  * @summary GetThreadListStackTraces returns wrong state for blocked VirtualThread
>> 28:  * @requires vm.continuations
>> 29:  * @modules java.base/java.lang:+open
> 
> I think `@modules` it's not needed

Thanks. Removed now.

> test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java line 34:
> 
>> 32: 
>> 33: import java.util.concurrent.locks.ReentrantLock;
>> 34: import java.util.concurrent.*;
> 
> unused imports

Thanks. Removed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14326#discussion_r1220495535
PR Review Comment: https://git.openjdk.org/jdk/pull/14326#discussion_r1220495047

From amenkov at openjdk.org  Tue Jun  6 23:01:51 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 6 Jun 2023 23:01:51 GMT
Subject: RFR: 8309509:
 com/sun/jdi/RedefineNestmateAttr/TestNestmateAttr.java fails with virtual test
 thread factory
In-Reply-To: <oqLBwARuJ3rFGRCxCEdnVbvNyLP1DxCHHixj5OYEJ3Y=.462f7350-24f7-4e41-9db5-8288f6c26b6d@github.com>
References: <oqLBwARuJ3rFGRCxCEdnVbvNyLP1DxCHHixj5OYEJ3Y=.462f7350-24f7-4e41-9db5-8288f6c26b6d@github.com>
Message-ID: <xMGPrk0wY0pa681R6lebYAHiqnnW2rgminxiumU_kIE=.edad39b6-8e72-4c99-a70e-0fa0942cfe98@github.com>

On Tue, 6 Jun 2023 00:02:47 GMT, Chris Plummer <cjplummer at openjdk.org> 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.

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14324#pullrequestreview-1466268017

From amenkov at openjdk.org  Tue Jun  6 23:04:54 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 6 Jun 2023 23:04:54 GMT
Subject: RFR: 8309420: com/sun/jdi/StepTest.java fails with virtual thread
 wrapper
In-Reply-To: <av9ig1PwtvEjkgBDkNizeyzkLb4IDuEgMbv9ABq8vhs=.fac3313d-291f-4c81-914d-a67d14916911@github.com>
References: <av9ig1PwtvEjkgBDkNizeyzkLb4IDuEgMbv9ABq8vhs=.fac3313d-291f-4c81-914d-a67d14916911@github.com>
Message-ID: <OJi4rEgur9JNpfXZOA7OZ-Di6FbRp38pjzposKP-Ln0=.040099d3-a3a4-4d09-9810-c6ca3eed92d6@github.com>

On Mon, 5 Jun 2023 04:03:57 GMT, Chris Plummer <cjplummer at openjdk.org> 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.

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14307#pullrequestreview-1466272033

From amenkov at openjdk.org  Tue Jun  6 23:23:55 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 6 Jun 2023 23:23:55 GMT
Subject: RFR: 8295976: GetThreadListStackTraces returns wrong state for
 blocked VirtualThread [v5]
In-Reply-To: <k8uygjjp4f42IN5Q4yeDOzGRTUEoh5DJg_s91r5lgwM=.d23c5ab3-8d02-4f2b-8c51-d6e2459d1f12@github.com>
References: <_bbL6afkGfa1lw1UFa26F4lGRiLQaiIkjo0tkDMUHm4=.0079cdec-34c0-45f4-836f-61118c111f43@github.com>
 <k8uygjjp4f42IN5Q4yeDOzGRTUEoh5DJg_s91r5lgwM=.d23c5ab3-8d02-4f2b-8c51-d6e2459d1f12@github.com>
Message-ID: <hCnnyQ_EOXorzi94MzUubp8SDxmlp-fNftaEXWn2YZ8=.07ff1103-5820-4e54-b17f-b7a09677951d@github.com>

On Tue, 6 Jun 2023 22:54:04 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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)
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: ThreadListStackTracesTest cleanup

test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java line 37:

> 35: import java.util.List;
> 36: import java.lang.reflect.Constructor;
> 37: import java.lang.reflect.InvocationTargetException;

I tried to comment all this lines, but something went wrong..
AFAIC the only required import is java.util.concurrent.locks.ReentrantLock, the rest are unused

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14326#discussion_r1220526323

From kdnilsen at openjdk.org  Tue Jun  6 23:24:33 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 6 Jun 2023 23:24:33 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v8]
In-Reply-To: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
Message-ID: <qYsLOsLZ9n-WPTgZnnkYdLPM3Mpk6IQyMPvklekx7Gc=.e65610b3-5b94-4d27-ad01-ff4596c76211@github.com>

> 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:

  Improve efficiency of card-size alignment calculations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14185/files
  - new: https://git.openjdk.org/jdk/pull/14185/files/cc149904..8f9e2a84

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14185&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14185&range=06-07

  Stats: 8 lines in 1 file changed: 0 ins; 4 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

From kdnilsen at openjdk.org  Tue Jun  6 23:24:34 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 6 Jun 2023 23:24:34 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v4]
In-Reply-To: <sjjq3q_tE5FxtYhZOYahzQfv5efaqf1POmnyeGD11Qc=.cfd6cd88-ec70-4d88-b9e0-2e8ca2732585@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <2sgbRGVCiStjmAspEqqpyWAM0IzbZfjFC6HHXlhbcyE=.9637c274-1b10-4103-b528-34719037362b@github.com>
 <sjjq3q_tE5FxtYhZOYahzQfv5efaqf1POmnyeGD11Qc=.cfd6cd88-ec70-4d88-b9e0-2e8ca2732585@github.com>
Message-ID: <DPy1wGBMKMytpeqq5lB3ZtrrRnlB6oVBVbH1gihAgOk=.dc864385-da6d-4c56-ad12-d10778990e0d@github.com>

On Fri, 2 Jun 2023 17:55:56 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Force PLAB sizes to align on card-table size
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1285:
> 
>> 1283:   if (unalignment != 0) {
>> 1284:     word_size = word_size - unalignment + CardTable::card_size_in_words();
>> 1285:   }
> 
> Probably not a big deal since this is only used when refilling a PLAB, which is an infrequent operation, but `mod` is an expensive operation, in general, and best to avoid in our code except in assertion checks (or even there given recent experiences with debug tests timing out). Since card size is a power of 2, may be we could use addition and masking instead. Something like defining the following inline in the CardTable class and using it everywhere where card alignment granularity is sought. There may even be a macro or method defined for this already perhaps:
> 
> 
> (FOO + CardSize - 1) & ~((1 << LogCardSize) - 1)
> 
> 
> One could even store the mask to avoid the arithmetic to produce the mask although it's pretty cheap.
> 
> This may turn out to be less expensive than mod, test, and branch, but as I said probably not a big deal here. We should make sure we don't overuse mods in our allocation paths much.

Thanks for this suggestion.  I've modified the code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1220523992

From amenkov at openjdk.org  Tue Jun  6 23:39:55 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 6 Jun 2023 23:39:55 GMT
Subject: RFR: 8307153: JVMTI GetThreadState on carrier should return
 STATE_WAITING [v4]
In-Reply-To: <GRu9lEuu6sVCRKbqaOniXipjdYQVSisid8Fu2eyZJEM=.45f6731c-8df6-4734-9e24-65b226e95ce7@github.com>
References: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>
 <SH2pr7y0t3C1v3EFDfgS4AArNAxNXbb1LTPC6xrKGI8=.2a629523-a681-4b61-988f-4df5e60e7a2b@github.com>
 <t-iQRZCgi0Jv6fpJDBRLID3Bhll-2ezYbVHfC7u79N0=.4db46ff4-351e-4737-81fb-b66ebb4358ed@github.com>
 <MkJ9Qmy6wtW_uzB2VXyFbfMujlzTgF_Tc_DM6n0z9HU=.de134484-9fa3-4ac9-a68f-5a2b3b5be59c@github.com>
 <chf9KOskdhm96pUVVgA9gIS2aPHPTnHQ3cAAjDRYJV4=.331b1bdd-3dc5-4f4a-ba15-9514f8b39ee6@github.com>
 <jRansukCg6_vwIh6V_bBvJu52yCBeczPELl4KEaKxmA=.61870be5-8131-46b8-ad93-e123e9027dff@github.com>
 <GRu9lEuu6sVCRKbqaOniXipjdYQVSisid8Fu2eyZJEM=.45f6731c-8df6-4734-9e24-65b226e95ce7@github.com>
Message-ID: <kwXABhGo8N0A_LiFW04VVahISpeHUgCCgCnenV8eGzw=.fbac4653-d6e8-4f52-bcf9-9473e923bfd8@github.com>

On Tue, 6 Jun 2023 22:06:14 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>>> Okay, I see you point. Unfortunately, I've always referred the platform thread with an executed FJP schedular as a carrier thread. The term 'carrier' with this meaning is everywhere in the JVMTI code. It looks very confusing to call a thread to be a carrier thread only during some phases of its execution.
>> 
>> Okay, I'm just pointing out that is_passive_carrier_thread looks a bit strange here as it is testing if a JavaThread is carrying a virtual thread oop -  it's not testing if the thread is owned by the virtual thread scheduler.
>
> I'm still thinking what identifier to use instead of `is_passive_carrier_thread`.
> Just `is_carrier_thread` is going to be confusing as well.
> What about `is_carrier_thread_waiting_for_virtual` or `is_carrier_thread_waiting_for_virtual_to_unmount`?

`is_carrying_carrier_thread`? a bit artificial, but it's a carrier thread and it's carrying a virtual thread

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14298#discussion_r1220541192

From kdnilsen at openjdk.org  Tue Jun  6 23:42:08 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 6 Jun 2023 23:42:08 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v4]
In-Reply-To: <-jrieUm3r32vA5At0baw1nTndtNGoxG6EBrcEDjwyZw=.0a95dc08-1259-418d-a9bb-b2ba86b18c51@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <2sgbRGVCiStjmAspEqqpyWAM0IzbZfjFC6HHXlhbcyE=.9637c274-1b10-4103-b528-34719037362b@github.com>
 <7uARcGDHOuSUugc2zRg7JQgC2dSPBDOjeWGPjBPO2qs=.a09479b8-ba9b-4596-bc5a-7ace0968fe31@github.com>
 <95yaqYTYoGnlkrDMbvZ-NTyVbGmHrL4DUYYIlV3wkwQ=.b6d787d2-3858-4486-b3dc-428a87969109@github.com>
 <-jrieUm3r32vA5At0baw1nTndtNGoxG6EBrcEDjwyZw=.0a95dc08-1259-418d-a9bb-b2ba86b18c51@github.com>
Message-ID: <Ebi_7Cn6YcEwa7L6ZuXmN0sZHVWLVT3nDcd4jB2m-xQ=.56df38ca-6249-47ff-990e-86e3983eab32@github.com>

On Sat, 3 Jun 2023 15:17:37 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Yes. And also from files which were changed by non-Amazon employees only, please.
>
> Thanks, Martin. Yes, we have noted that there were a few other files that were inadvertently caught in a copyright header dragnet. These will be reviewed and fixed in https://bugs.openjdk.org/browse/JDK-8309392 .

I'm fixing this copyright notice and others.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1220542561

From amenkov at openjdk.org  Tue Jun  6 23:44:55 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 6 Jun 2023 23:44:55 GMT
Subject: RFR: 8307153: JVMTI GetThreadState on carrier should return
 STATE_WAITING [v4]
In-Reply-To: <UUIMk0DSyDCcAPQPQjFIZr4SLLMFn2TKx-bxYl2xPAA=.25db26ee-97a4-48bd-965c-3c90868b51df@github.com>
References: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>
 <UUIMk0DSyDCcAPQPQjFIZr4SLLMFn2TKx-bxYl2xPAA=.25db26ee-97a4-48bd-965c-3c90868b51df@github.com>
Message-ID: <XAHXvxQ36aX03mc-Vt2JBrkldlz4jTKs6RJE0C8_Fl8=.edf8646f-bcb9-4832-868a-ad4a0bac6643@github.com>

On Tue, 6 Jun 2023 22:41:54 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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: call get_thread_state_base only when needed

Marked as reviewed by amenkov (Reviewer).

src/hotspot/share/prims/jvmtiEnvBase.hpp line 386:

> 384: 
> 385:   // get platform thread state
> 386:   static jint get_thread_state_base(oop thread_oop, JavaThread* jt);

maybe rename it to `get_platform_thread_state`?

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

PR Review: https://git.openjdk.org/jdk/pull/14298#pullrequestreview-1466301122
PR Review Comment: https://git.openjdk.org/jdk/pull/14298#discussion_r1220543652

From sspitsyn at openjdk.org  Tue Jun  6 23:44:57 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 Jun 2023 23:44:57 GMT
Subject: RFR: 8307153: JVMTI GetThreadState on carrier should return
 STATE_WAITING [v4]
In-Reply-To: <kwXABhGo8N0A_LiFW04VVahISpeHUgCCgCnenV8eGzw=.fbac4653-d6e8-4f52-bcf9-9473e923bfd8@github.com>
References: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>
 <SH2pr7y0t3C1v3EFDfgS4AArNAxNXbb1LTPC6xrKGI8=.2a629523-a681-4b61-988f-4df5e60e7a2b@github.com>
 <t-iQRZCgi0Jv6fpJDBRLID3Bhll-2ezYbVHfC7u79N0=.4db46ff4-351e-4737-81fb-b66ebb4358ed@github.com>
 <MkJ9Qmy6wtW_uzB2VXyFbfMujlzTgF_Tc_DM6n0z9HU=.de134484-9fa3-4ac9-a68f-5a2b3b5be59c@github.com>
 <chf9KOskdhm96pUVVgA9gIS2aPHPTnHQ3cAAjDRYJV4=.331b1bdd-3dc5-4f4a-ba15-9514f8b39ee6@github.com>
 <jRansukCg6_vwIh6V_bBvJu52yCBeczPELl4KEaKxmA=.61870be5-8131-46b8-ad93-e123e9027dff@github.com>
 <GRu9lEuu6sVCRKbqaOniXipjdYQVSisid8Fu2eyZJEM=.45f6731c-8df6-4734-9e24-65b226e95ce7@github.com>
 <kwXABhGo8N0A_LiFW04VVahISpeHUgCCgCnenV8eGzw=.fbac4653-d6e8-4f52-bcf9-9473e923bfd8@github.com>
Message-ID: <U-teCmrMm46wz5y7JBBtBOZrVHLdAmDSIIYdVkdGjNE=.8ec98935-e7c6-42a3-b35f-a778a6a230d2@github.com>

On Tue, 6 Jun 2023 23:37:03 GMT, Alex Menkov <amenkov at openjdk.org> 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.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14298#discussion_r1220546031

From sspitsyn at openjdk.org  Tue Jun  6 23:45:22 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 Jun 2023 23:45:22 GMT
Subject: RFR: 8295976: GetThreadListStackTraces returns wrong state for
 blocked VirtualThread [v6]
In-Reply-To: <_bbL6afkGfa1lw1UFa26F4lGRiLQaiIkjo0tkDMUHm4=.0079cdec-34c0-45f4-836f-61118c111f43@github.com>
References: <_bbL6afkGfa1lw1UFa26F4lGRiLQaiIkjo0tkDMUHm4=.0079cdec-34c0-45f4-836f-61118c111f43@github.com>
Message-ID: <BGHrPc_oHUdVkra_awu6UMahZ6456hDAOgkP23U8bn0=.fd78c9da-bf81-4dd2-8633-7a1258ca08bf@github.com>

> 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)

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: remove unused imports from ThreadListStackTracesTest.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14326/files
  - new: https://git.openjdk.org/jdk/pull/14326/files/6b685ca3..7506b539

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14326&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14326&range=04-05

  Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14326.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14326/head:pull/14326

PR: https://git.openjdk.org/jdk/pull/14326

From sspitsyn at openjdk.org  Tue Jun  6 23:45:22 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 Jun 2023 23:45:22 GMT
Subject: RFR: 8295976: GetThreadListStackTraces returns wrong state for
 blocked VirtualThread [v5]
In-Reply-To: <hCnnyQ_EOXorzi94MzUubp8SDxmlp-fNftaEXWn2YZ8=.07ff1103-5820-4e54-b17f-b7a09677951d@github.com>
References: <_bbL6afkGfa1lw1UFa26F4lGRiLQaiIkjo0tkDMUHm4=.0079cdec-34c0-45f4-836f-61118c111f43@github.com>
 <k8uygjjp4f42IN5Q4yeDOzGRTUEoh5DJg_s91r5lgwM=.d23c5ab3-8d02-4f2b-8c51-d6e2459d1f12@github.com>
 <hCnnyQ_EOXorzi94MzUubp8SDxmlp-fNftaEXWn2YZ8=.07ff1103-5820-4e54-b17f-b7a09677951d@github.com>
Message-ID: <SxC9Oo-fU95e39yW7FX1qmiW-C-0eDIe92mz36Qi454=.c01f46fc-c830-4fdd-bf34-9b13cc7b7120@github.com>

On Tue, 6 Jun 2023 23:20:53 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: ThreadListStackTracesTest cleanup
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java line 37:
> 
>> 35: import java.util.List;
>> 36: import java.lang.reflect.Constructor;
>> 37: import java.lang.reflect.InvocationTargetException;
> 
> I tried to comment all this lines, but something went wrong..
> AFAIC the only required import is java.util.concurrent.locks.ReentrantLock, the rest are unused

Thanks. Fixed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14326#discussion_r1220538628

From sspitsyn at openjdk.org  Tue Jun  6 23:56:55 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 6 Jun 2023 23:56:55 GMT
Subject: RFR: 8307153: JVMTI GetThreadState on carrier should return
 STATE_WAITING [v4]
In-Reply-To: <XAHXvxQ36aX03mc-Vt2JBrkldlz4jTKs6RJE0C8_Fl8=.edf8646f-bcb9-4832-868a-ad4a0bac6643@github.com>
References: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>
 <UUIMk0DSyDCcAPQPQjFIZr4SLLMFn2TKx-bxYl2xPAA=.25db26ee-97a4-48bd-965c-3c90868b51df@github.com>
 <XAHXvxQ36aX03mc-Vt2JBrkldlz4jTKs6RJE0C8_Fl8=.edf8646f-bcb9-4832-868a-ad4a0bac6643@github.com>
Message-ID: <e1DfQqIaLGBaj4KgoaFoARPF_w7sNaURS3IhBbIl7cY=.c05f5986-7fcd-4c2e-986b-f94e6e10654c@github.com>

On Tue, 6 Jun 2023 23:39:54 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: call get_thread_state_base only when needed
>
> src/hotspot/share/prims/jvmtiEnvBase.hpp line 386:
> 
>> 384: 
>> 385:   // get platform thread state
>> 386:   static jint get_thread_state_base(oop thread_oop, JavaThread* jt);
> 
> maybe rename it to `get_platform_thread_state`?

I was thinking about it. It will be inconsistent with`get_vthread_state`.
Ideally, then the `get_vthread_state` needs to be replaced with the `get_virtual_thread_state`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14298#discussion_r1220559583

From kdnilsen at openjdk.org  Wed Jun  7 00:39:52 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 7 Jun 2023 00:39:52 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v9]
In-Reply-To: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
Message-ID: <5tvdtUZnFnmoUyyVFYoOZm_KtVSzjfzBI7aPXpCpgVw=.2c09ff27-4004-44f3-b86d-a88d2f43a2a8@github.com>

> 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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14185/files
  - new: https://git.openjdk.org/jdk/pull/14185/files/8f9e2a84..f6c073a5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14185&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14185&range=07-08

  Stats: 7 lines in 6 files changed: 0 ins; 5 del; 2 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

From amenkov at openjdk.org  Wed Jun  7 01:08:05 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 7 Jun 2023 01:08:05 GMT
Subject: RFR: 8307153: JVMTI GetThreadState on carrier should return
 STATE_WAITING [v4]
In-Reply-To: <U-teCmrMm46wz5y7JBBtBOZrVHLdAmDSIIYdVkdGjNE=.8ec98935-e7c6-42a3-b35f-a778a6a230d2@github.com>
References: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>
 <SH2pr7y0t3C1v3EFDfgS4AArNAxNXbb1LTPC6xrKGI8=.2a629523-a681-4b61-988f-4df5e60e7a2b@github.com>
 <t-iQRZCgi0Jv6fpJDBRLID3Bhll-2ezYbVHfC7u79N0=.4db46ff4-351e-4737-81fb-b66ebb4358ed@github.com>
 <MkJ9Qmy6wtW_uzB2VXyFbfMujlzTgF_Tc_DM6n0z9HU=.de134484-9fa3-4ac9-a68f-5a2b3b5be59c@github.com>
 <chf9KOskdhm96pUVVgA9gIS2aPHPTnHQ3cAAjDRYJV4=.331b1bdd-3dc5-4f4a-ba15-9514f8b39ee6@github.com>
 <jRansukCg6_vwIh6V_bBvJu52yCBeczPELl4KEaKxmA=.61870be5-8131-46b8-ad93-e123e9027dff@github.com>
 <GRu9lEuu6sVCRKbqaOniXipjdYQVSisid8Fu2eyZJEM=.45f6731c-8df6-4734-9e24-65b226e95ce7@github.com>
 <kwXABhGo8N0A_LiFW04VVahISpeHUgCCgCnenV8eGzw=.fbac4653-d6e8-4f52-bcf9-9473e923bfd8@github.com>
 <U-teCmrMm46wz5y7JBBtBOZrVHLdAmDSIIYdVkdGjNE=.8ec98935-e7c6-42a3-b35f-a778a6a230d2@github.com>
Message-ID: <hf8CZ4cGmT-xm_SaiWZvMBlsLXTHacKNK_pVqKhHGv0=.28fdbd1e-8c53-42b7-8090-55e4498c9b40@github.com>

On Tue, 6 Jun 2023 23:42:24 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14298#discussion_r1220627250

From ysr at openjdk.org  Wed Jun  7 03:41:13 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 7 Jun 2023 03:41:13 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v9]
In-Reply-To: <5tvdtUZnFnmoUyyVFYoOZm_KtVSzjfzBI7aPXpCpgVw=.2c09ff27-4004-44f3-b86d-a88d2f43a2a8@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <5tvdtUZnFnmoUyyVFYoOZm_KtVSzjfzBI7aPXpCpgVw=.2c09ff27-4004-44f3-b86d-a88d2f43a2a8@github.com>
Message-ID: <ptmNwZZCSIJMMKlr_d1_NGo1ogXrn6wH8icplvWkTRA=.ce867855-b6a2-49f9-b8a3-b80df0634c8e@github.com>

On Wed, 7 Jun 2023 00:39:52 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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

> Hi, I have built this pr based on [aa85a90](https://github.com/openjdk/jdk/commit/aa85a9073e2a71d6bf920409e739d555f9dcf302), Tier1 tests failed on `gc/TestAllocHumongousFragment.java#generational` on Linux/RISC-V with the following output:
> 
> ```
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (shenandoahVerifier.cpp:1244), pid=2951116, tid=2951124
> #  Error: Verify init-mark remembered set violation; clean card should be dirty
> #
> # JRE version: OpenJDK Runtime Environment (21.0) (build 21-internal-adhoc.ubuntu.jdk)
> # Java VM: OpenJDK 64-Bit Server VM (21-internal-adhoc.ubuntu.jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, shenandoah gc, linux-riscv64)
> ```
> 
> Looks like Generational Shenandoah does not fully support RISC-V port, should we disable this test on RISC-V port for now?

Fixed (platform disabled) by @kdnilsen in https://github.com/openjdk/jdk/pull/14185/commits/cc149904d76c78355fc994da171f0f21411e903f

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

PR Comment: https://git.openjdk.org/jdk/pull/14185#issuecomment-1579829038

From cjplummer at openjdk.org  Wed Jun  7 04:48:59 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 7 Jun 2023 04:48:59 GMT
Subject: RFR: 8307153: JVMTI GetThreadState on carrier should return
 STATE_WAITING [v4]
In-Reply-To: <UUIMk0DSyDCcAPQPQjFIZr4SLLMFn2TKx-bxYl2xPAA=.25db26ee-97a4-48bd-965c-3c90868b51df@github.com>
References: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>
 <UUIMk0DSyDCcAPQPQjFIZr4SLLMFn2TKx-bxYl2xPAA=.25db26ee-97a4-48bd-965c-3c90868b51df@github.com>
Message-ID: <0g78gMSXw683BQh9UYpDXbpDgBOS5DsIP9df5Qr3XUM=.5c557de4-8b29-4a3f-9e83-ed23a853739f@github.com>

On Tue, 6 Jun 2023 22:41:54 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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: call get_thread_state_base only when needed

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14298#pullrequestreview-1466591721

From alanb at openjdk.org  Wed Jun  7 05:53:56 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Jun 2023 05:53:56 GMT
Subject: RFR: 8307153: JVMTI GetThreadState on carrier should return
 STATE_WAITING [v4]
In-Reply-To: <hf8CZ4cGmT-xm_SaiWZvMBlsLXTHacKNK_pVqKhHGv0=.28fdbd1e-8c53-42b7-8090-55e4498c9b40@github.com>
References: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>
 <SH2pr7y0t3C1v3EFDfgS4AArNAxNXbb1LTPC6xrKGI8=.2a629523-a681-4b61-988f-4df5e60e7a2b@github.com>
 <t-iQRZCgi0Jv6fpJDBRLID3Bhll-2ezYbVHfC7u79N0=.4db46ff4-351e-4737-81fb-b66ebb4358ed@github.com>
 <MkJ9Qmy6wtW_uzB2VXyFbfMujlzTgF_Tc_DM6n0z9HU=.de134484-9fa3-4ac9-a68f-5a2b3b5be59c@github.com>
 <chf9KOskdhm96pUVVgA9gIS2aPHPTnHQ3cAAjDRYJV4=.331b1bdd-3dc5-4f4a-ba15-9514f8b39ee6@github.com>
 <jRansukCg6_vwIh6V_bBvJu52yCBeczPELl4KEaKxmA=.61870be5-8131-46b8-ad93-e123e9027dff@github.com>
 <GRu9lEuu6sVCRKbqaOniXipjdYQVSisid8Fu2eyZJEM=.45f6731c-8df6-4734-9e24-65b226e95ce7@github.com>
 <kwXABhGo8N0A_LiFW04VVahISpeHUgCCgCnenV8eGzw=.fbac4653-d6e8-4f52-bcf9-9473e923bfd8@github.com>
 <U-teCmrMm46wz5y7JBBtBOZrVHLdAmDSIIYdVkdGjNE=.8ec98935-e7c6-42a3-b35f-a778a6a230d2@github.com>
 <hf8CZ4cGmT-xm_SaiWZvMBlsLXTHacKNK_pVqKhHGv0=.28fdbd1e-8c53-42b7-8090-55e4498c9b40@github.com>
Message-ID: <FekX1GulqLM_pK3SwhyZp527J2UnAy5npAjUjX8wIIw=.ec2dd827-90b0-4123-9010-c89f15d7ec81@github.com>

On Wed, 7 Jun 2023 01:05:07 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> 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.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14298#discussion_r1220891958

From avu at openjdk.org  Wed Jun  7 07:00:59 2023
From: avu at openjdk.org (Alexey Ushakov)
Date: Wed, 7 Jun 2023 07:00:59 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v4]
In-Reply-To: <gMtRBStdo62ZscHEotlSWQ70g-EiN_wJGNLRY910KUw=.0b899a67-1cad-45f6-a7d8-d539f7cc8af1@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <gMtRBStdo62ZscHEotlSWQ70g-EiN_wJGNLRY910KUw=.0b899a67-1cad-45f6-a7d8-d539f7cc8af1@github.com>
Message-ID: <u9aRCuCviWT1Fo5TU683Yn535tbzFEL6glx-Z1gMZAw=.1e9071f3-18ef-440d-80a7-c53fb627ca49@github.com>

On Thu, 1 Jun 2023 15:01:37 GMT, Artem Semenov <asemenov at openjdk.org> 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

From ysr at openjdk.org  Wed Jun  7 07:25:16 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 7 Jun 2023 07:25:16 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v9]
In-Reply-To: <5tvdtUZnFnmoUyyVFYoOZm_KtVSzjfzBI7aPXpCpgVw=.2c09ff27-4004-44f3-b86d-a88d2f43a2a8@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <5tvdtUZnFnmoUyyVFYoOZm_KtVSzjfzBI7aPXpCpgVw=.2c09ff27-4004-44f3-b86d-a88d2f43a2a8@github.com>
Message-ID: <fG_3AzSBHgU4KsBWzxtAfpvfwVJQ24EawmUVpTREnHY=.108b22ec-04ff-4af0-934f-71efb9ed3f06@github.com>

On Wed, 7 Jun 2023 00:39:52 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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

From ysr at openjdk.org  Wed Jun  7 07:43:20 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 7 Jun 2023 07:43:20 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v9]
In-Reply-To: <5tvdtUZnFnmoUyyVFYoOZm_KtVSzjfzBI7aPXpCpgVw=.2c09ff27-4004-44f3-b86d-a88d2f43a2a8@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <5tvdtUZnFnmoUyyVFYoOZm_KtVSzjfzBI7aPXpCpgVw=.2c09ff27-4004-44f3-b86d-a88d2f43a2a8@github.com>
Message-ID: <oYom4NtPJPDwG1ZxdCcc8xh0ZUdTff-IzrfWgi-rHwE=.5a0c0bfc-2fbd-4589-9bb5-114877add85b@github.com>

On Wed, 7 Jun 2023 00:39:52 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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:  * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved.

Can be removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221051315
PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221054767
PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221056157
PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221056909
PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221058681
PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221060221
PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221060613
PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221061900
PR Review Comment: https://git.openjdk.org/jdk/pull/14185#discussion_r1221063047

From ysr at openjdk.org  Wed Jun  7 07:46:20 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 7 Jun 2023 07:46:20 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v9]
In-Reply-To: <5tvdtUZnFnmoUyyVFYoOZm_KtVSzjfzBI7aPXpCpgVw=.2c09ff27-4004-44f3-b86d-a88d2f43a2a8@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <5tvdtUZnFnmoUyyVFYoOZm_KtVSzjfzBI7aPXpCpgVw=.2c09ff27-4004-44f3-b86d-a88d2f43a2a8@github.com>
Message-ID: <u-xADPusx-SyWF8MLtksyIyF1hmhP6SnbCZziYZHChg=.5b1f8541-e406-49d5-8b2e-469dd3a89db1@github.com>

On Wed, 7 Jun 2023 00:39:52 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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

From stuefe at openjdk.org  Wed Jun  7 07:50:20 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 7 Jun 2023 07:50:20 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v9]
In-Reply-To: <5tvdtUZnFnmoUyyVFYoOZm_KtVSzjfzBI7aPXpCpgVw=.2c09ff27-4004-44f3-b86d-a88d2f43a2a8@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <5tvdtUZnFnmoUyyVFYoOZm_KtVSzjfzBI7aPXpCpgVw=.2c09ff27-4004-44f3-b86d-a88d2f43a2a8@github.com>
Message-ID: <pNnvf7YYaCsL3V2wokflgmBD5OjVmzZdqvvmnJmV1Kg=.ffe17b90-569e-4ae5-a150-3b0425a58294@github.com>

On Wed, 7 Jun 2023 00:39:52 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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:

> <snip>

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

From ysr at openjdk.org  Wed Jun  7 07:50:20 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 7 Jun 2023 07:50:20 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v9]
In-Reply-To: <5tvdtUZnFnmoUyyVFYoOZm_KtVSzjfzBI7aPXpCpgVw=.2c09ff27-4004-44f3-b86d-a88d2f43a2a8@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <5tvdtUZnFnmoUyyVFYoOZm_KtVSzjfzBI7aPXpCpgVw=.2c09ff27-4004-44f3-b86d-a88d2f43a2a8@github.com>
Message-ID: <11_EM-LgCnPY9x_t3s6wz3-oh8eN_e-GMlo2mWtiHbc=.4ade74ee-6f36-4621-b911-dce9e127cd98@github.com>

On Wed, 7 Jun 2023 00:39:52 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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

From sspitsyn at openjdk.org  Wed Jun  7 07:55:13 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 7 Jun 2023 07:55:13 GMT
Subject: Integrated: 8295976: GetThreadListStackTraces returns wrong state for
 blocked VirtualThread
In-Reply-To: <_bbL6afkGfa1lw1UFa26F4lGRiLQaiIkjo0tkDMUHm4=.0079cdec-34c0-45f4-836f-61118c111f43@github.com>
References: <_bbL6afkGfa1lw1UFa26F4lGRiLQaiIkjo0tkDMUHm4=.0079cdec-34c0-45f4-836f-61118c111f43@github.com>
Message-ID: <RgDwFwJ7L8ivsF9gAyKs0o2CariQUmQgQ34ew8MsGTk=.81c50597-0e93-4d3b-8aa0-224508ad7996@github.com>

On Tue, 6 Jun 2023 00:50:34 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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 <sspitsyn at openjdk.org>
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

From ysr at openjdk.org  Wed Jun  7 07:58:22 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 7 Jun 2023 07:58:22 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v9]
In-Reply-To: <5tvdtUZnFnmoUyyVFYoOZm_KtVSzjfzBI7aPXpCpgVw=.2c09ff27-4004-44f3-b86d-a88d2f43a2a8@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <5tvdtUZnFnmoUyyVFYoOZm_KtVSzjfzBI7aPXpCpgVw=.2c09ff27-4004-44f3-b86d-a88d2f43a2a8@github.com>
Message-ID: <ll2F5iewKHlhTTAWwK3t3HfUOYL38YcIOiRHQPKAYpM=.b678a515-a5f1-4ab4-927d-a62a9d858b17@github.com>

On Wed, 7 Jun 2023 00:39:52 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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

From ysr at openjdk.org  Wed Jun  7 08:12:28 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 7 Jun 2023 08:12:28 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v9]
In-Reply-To: <5tvdtUZnFnmoUyyVFYoOZm_KtVSzjfzBI7aPXpCpgVw=.2c09ff27-4004-44f3-b86d-a88d2f43a2a8@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <5tvdtUZnFnmoUyyVFYoOZm_KtVSzjfzBI7aPXpCpgVw=.2c09ff27-4004-44f3-b86d-a88d2f43a2a8@github.com>
Message-ID: <cSadJM3L-TTcgt3p-o7wHbV_1Tcw125F1Uo3L-hFwJA=.666ef7ed-e1e5-4d9a-b7d1-b3be9b2c2f69@github.com>

On Wed, 7 Jun 2023 00:39:52 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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

From ysr at openjdk.org  Wed Jun  7 08:17:22 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 7 Jun 2023 08:17:22 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v9]
In-Reply-To: <5tvdtUZnFnmoUyyVFYoOZm_KtVSzjfzBI7aPXpCpgVw=.2c09ff27-4004-44f3-b86d-a88d2f43a2a8@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <5tvdtUZnFnmoUyyVFYoOZm_KtVSzjfzBI7aPXpCpgVw=.2c09ff27-4004-44f3-b86d-a88d2f43a2a8@github.com>
Message-ID: <aFrGUEzEDoNJxFAs_yE0Fe1tiXYAGXGK8OiMSrAPvC0=.f68672dc-0596-4e67-b5aa-39898d738905@github.com>

On Wed, 7 Jun 2023 00:39:52 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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

From ysr at openjdk.org  Wed Jun  7 08:26:18 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 7 Jun 2023 08:26:18 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v9]
In-Reply-To: <5tvdtUZnFnmoUyyVFYoOZm_KtVSzjfzBI7aPXpCpgVw=.2c09ff27-4004-44f3-b86d-a88d2f43a2a8@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <5tvdtUZnFnmoUyyVFYoOZm_KtVSzjfzBI7aPXpCpgVw=.2c09ff27-4004-44f3-b86d-a88d2f43a2a8@github.com>
Message-ID: <47uWbayDcFRkkQ5crcpFyIFGvBwM0yCAXvxeIonOdcI=.5387f07c-d89f-4839-acdd-bb49d686a2d7@github.com>

On Wed, 7 Jun 2023 00:39:52 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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

From sspitsyn at openjdk.org  Wed Jun  7 11:31:02 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 7 Jun 2023 11:31:02 GMT
Subject: RFR: 8307153: JVMTI GetThreadState on carrier should return
 STATE_WAITING [v5]
In-Reply-To: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>
References: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>
Message-ID: <tkO5xvkgYhDWchZynCSYEnP7K_JDnCokgjIkkZyc0b8=.23aff0ab-1f5a-47a2-aa0c-d1b5084bdf17@github.com>

> 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/77771816..3e7618c4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14298&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14298&range=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

From sspitsyn at openjdk.org  Wed Jun  7 11:31:06 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 7 Jun 2023 11:31:06 GMT
Subject: RFR: 8307153: JVMTI GetThreadState on carrier should return
 STATE_WAITING [v5]
In-Reply-To: <FekX1GulqLM_pK3SwhyZp527J2UnAy5npAjUjX8wIIw=.ec2dd827-90b0-4123-9010-c89f15d7ec81@github.com>
References: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>
 <SH2pr7y0t3C1v3EFDfgS4AArNAxNXbb1LTPC6xrKGI8=.2a629523-a681-4b61-988f-4df5e60e7a2b@github.com>
 <t-iQRZCgi0Jv6fpJDBRLID3Bhll-2ezYbVHfC7u79N0=.4db46ff4-351e-4737-81fb-b66ebb4358ed@github.com>
 <MkJ9Qmy6wtW_uzB2VXyFbfMujlzTgF_Tc_DM6n0z9HU=.de134484-9fa3-4ac9-a68f-5a2b3b5be59c@github.com>
 <chf9KOskdhm96pUVVgA9gIS2aPHPTnHQ3cAAjDRYJV4=.331b1bdd-3dc5-4f4a-ba15-9514f8b39ee6@github.com>
 <jRansukCg6_vwIh6V_bBvJu52yCBeczPELl4KEaKxmA=.61870be5-8131-46b8-ad93-e123e9027dff@github.com>
 <GRu9lEuu6sVCRKbqaOniXipjdYQVSisid8Fu2eyZJEM=.45f6731c-8df6-4734-9e24-65b226e95ce7@github.com>
 <kwXABhGo8N0A_LiFW04VVahISpeHUgCCgCnenV8eGzw=.fbac4653-d6e8-4f52-bcf9-9473e923bfd8@github.com>
 <U-teCmrMm46wz5y7JBBtBOZrVHLdAmDSIIYdVkdGjNE=.8ec98935-e7c6-42a3-b35f-a778a6a230d2@github.com>
 <hf8CZ4cGmT-xm_SaiWZvMBlsLXTHacKNK_pVqKhHGv0=.28fdbd1e-8c53-42b7-8090-55e4498c9b40@github.com>
 <FekX1GulqLM_pK3SwhyZp527J2UnAy5npAj
 UjX8wIIw=.ec2dd827-90b0-4123-9010-c89f15d7ec81@github.com>
Message-ID: <dGl3O6TK_Y1Cql05GcvHqZFcYB5O_12xg5Uy-2eeiDc=.791f6e4d-db5a-4085-a6f4-09fd59ca75da@github.com>

On Wed, 7 Jun 2023 05:50:46 GMT, Alan Bateman <alanb at openjdk.org> 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

From sspitsyn at openjdk.org  Wed Jun  7 11:48:19 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 7 Jun 2023 11:48:19 GMT
Subject: RFR: 8307153: JVMTI GetThreadState on carrier should return
 STATE_WAITING [v6]
In-Reply-To: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>
References: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>
Message-ID: <ZCtBzX0ve4-qwkfC8HKRdztiTLrJO2VZQdac-UM0ht4=.514c4bd1-51e0-4ae6-8668-3386a79b37a2@github.com>

> 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&pr=14298&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14298&range=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

From sspitsyn at openjdk.org  Wed Jun  7 11:53:57 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 7 Jun 2023 11:53:57 GMT
Subject: RFR: 8307153: JVMTI GetThreadState on carrier should return
 STATE_WAITING [v6]
In-Reply-To: <ZCtBzX0ve4-qwkfC8HKRdztiTLrJO2VZQdac-UM0ht4=.514c4bd1-51e0-4ae6-8668-3386a79b37a2@github.com>
References: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>
 <ZCtBzX0ve4-qwkfC8HKRdztiTLrJO2VZQdac-UM0ht4=.514c4bd1-51e0-4ae6-8668-3386a79b37a2@github.com>
Message-ID: <CQN-hKfYqGYLhYEJeOmwWsiwpiep03-xvvdik7vxDCE=.f5f9f21b-0034-44fc-a13a-2d318e400b8e@github.com>

On Wed, 7 Jun 2023 11:48:19 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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

From kdnilsen at openjdk.org  Wed Jun  7 12:31:18 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 7 Jun 2023 12:31:18 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v9]
In-Reply-To: <fG_3AzSBHgU4KsBWzxtAfpvfwVJQ24EawmUVpTREnHY=.108b22ec-04ff-4af0-934f-71efb9ed3f06@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <5tvdtUZnFnmoUyyVFYoOZm_KtVSzjfzBI7aPXpCpgVw=.2c09ff27-4004-44f3-b86d-a88d2f43a2a8@github.com>
 <fG_3AzSBHgU4KsBWzxtAfpvfwVJQ24EawmUVpTREnHY=.108b22ec-04ff-4af0-934f-71efb9ed3f06@github.com>
Message-ID: <ucFaOwoAOycAEbY6Q3JjkJq6-qlAv9jVJrwshlnZdLY=.784df384-ff18-4dff-82a8-8a60ede2a385@github.com>

On Wed, 7 Jun 2023 07:22:13 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> 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

From kdnilsen at openjdk.org  Wed Jun  7 12:37:42 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 7 Jun 2023 12:37:42 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v10]
In-Reply-To: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
Message-ID: <mAyNqAVyLOmsEzlEEe9dONq-SeQ4R5lxIgskpr1viOQ=.341579a1-07c9-4ff1-90b3-1e522a0b7064@github.com>

> 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&pr=14185&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14185&range=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

From sspitsyn at openjdk.org  Wed Jun  7 12:40:08 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 7 Jun 2023 12:40:08 GMT
Subject: RFR: 8309602: update JVMTI history table for jdk 21
Message-ID: <n07_y3NMnvJFFNJBV7dbuoMNlLP1cymGyYNiupbbnsg=.00eaf437-3edf-4e1b-bf5f-8136c0c1183c@github.com>

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&pr=14352&range=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

From kdnilsen at openjdk.org  Wed Jun  7 12:44:53 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 7 Jun 2023 12:44:53 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v11]
In-Reply-To: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
Message-ID: <1g_0xe2WOXuGOGYZ02225hi4yyz6OKWsRxVNrpZjhhE=.bacf7c2e-24d4-4060-8cff-7e27cd6f3721@github.com>

> 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&pr=14185&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14185&range=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

From sspitsyn at openjdk.org  Wed Jun  7 12:57:34 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 7 Jun 2023 12:57:34 GMT
Subject: RFR: 8309602: update JVMTI history table for jdk 21 [v2]
In-Reply-To: <n07_y3NMnvJFFNJBV7dbuoMNlLP1cymGyYNiupbbnsg=.00eaf437-3edf-4e1b-bf5f-8136c0c1183c@github.com>
References: <n07_y3NMnvJFFNJBV7dbuoMNlLP1cymGyYNiupbbnsg=.00eaf437-3edf-4e1b-bf5f-8136c0c1183c@github.com>
Message-ID: <ybEkM2rrJzAOJubdOB-pBmHYSA58L8WXOdmdsNxB0mg=.bd6c7edf-c1fe-4570-a625-b6cfd9278513@github.com>

> 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&pr=14352&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14352&range=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

From alanb at openjdk.org  Wed Jun  7 12:58:56 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Jun 2023 12:58:56 GMT
Subject: RFR: 8309602: update JVMTI history table for jdk 21 [v2]
In-Reply-To: <ybEkM2rrJzAOJubdOB-pBmHYSA58L8WXOdmdsNxB0mg=.bd6c7edf-c1fe-4570-a625-b6cfd9278513@github.com>
References: <n07_y3NMnvJFFNJBV7dbuoMNlLP1cymGyYNiupbbnsg=.00eaf437-3edf-4e1b-bf5f-8136c0c1183c@github.com>
 <ybEkM2rrJzAOJubdOB-pBmHYSA58L8WXOdmdsNxB0mg=.bd6c7edf-c1fe-4570-a625-b6cfd9278513@github.com>
Message-ID: <fuVL8fncoUWrLgcl5R8YH8h9RrubEAK7EXdf0c7bxGw=.68d5e9db-dbba-4cf2-81b7-83094410e950@github.com>

On Wed, 7 Jun 2023 12:57:34 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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:   </change>
> 15458:   <change date="27 April 2022" version="19.0.0">
> 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:   </change>

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

From sspitsyn at openjdk.org  Wed Jun  7 13:08:00 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 7 Jun 2023 13:08:00 GMT
Subject: RFR: 8309602: update JVMTI history table for jdk 21 [v3]
In-Reply-To: <n07_y3NMnvJFFNJBV7dbuoMNlLP1cymGyYNiupbbnsg=.00eaf437-3edf-4e1b-bf5f-8136c0c1183c@github.com>
References: <n07_y3NMnvJFFNJBV7dbuoMNlLP1cymGyYNiupbbnsg=.00eaf437-3edf-4e1b-bf5f-8136c0c1183c@github.com>
Message-ID: <2cVTkVoKxRkH6B_a7B6Toc6hK5IWhnwJkBX0hnP_g-0=.e169eba0-bf85-4a9c-b227-211c5315d74a@github.com>

> 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&pr=14352&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14352&range=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

From sspitsyn at openjdk.org  Wed Jun  7 13:08:03 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 7 Jun 2023 13:08:03 GMT
Subject: RFR: 8309602: update JVMTI history table for jdk 21 [v2]
In-Reply-To: <fuVL8fncoUWrLgcl5R8YH8h9RrubEAK7EXdf0c7bxGw=.68d5e9db-dbba-4cf2-81b7-83094410e950@github.com>
References: <n07_y3NMnvJFFNJBV7dbuoMNlLP1cymGyYNiupbbnsg=.00eaf437-3edf-4e1b-bf5f-8136c0c1183c@github.com>
 <ybEkM2rrJzAOJubdOB-pBmHYSA58L8WXOdmdsNxB0mg=.bd6c7edf-c1fe-4570-a625-b6cfd9278513@github.com>
 <fuVL8fncoUWrLgcl5R8YH8h9RrubEAK7EXdf0c7bxGw=.68d5e9db-dbba-4cf2-81b7-83094410e950@github.com>
Message-ID: <3iju4FBlvcDEeRLIAUCPoV-nZEIuJnrka8cSN-qFmUA=.ab40cb6b-31be-4ecc-aa15-040f1dc9ffac@github.com>

On Wed, 7 Jun 2023 12:55:27 GMT, Alan Bateman <alanb at openjdk.org> 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:   </change>
>> 15458:   <change date="27 April 2022" version="19.0.0">
>> 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

From sspitsyn at openjdk.org  Wed Jun  7 13:09:57 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 7 Jun 2023 13:09:57 GMT
Subject: RFR: 8309602: update JVMTI history table for jdk 21 [v2]
In-Reply-To: <fuVL8fncoUWrLgcl5R8YH8h9RrubEAK7EXdf0c7bxGw=.68d5e9db-dbba-4cf2-81b7-83094410e950@github.com>
References: <n07_y3NMnvJFFNJBV7dbuoMNlLP1cymGyYNiupbbnsg=.00eaf437-3edf-4e1b-bf5f-8136c0c1183c@github.com>
 <ybEkM2rrJzAOJubdOB-pBmHYSA58L8WXOdmdsNxB0mg=.bd6c7edf-c1fe-4570-a625-b6cfd9278513@github.com>
 <fuVL8fncoUWrLgcl5R8YH8h9RrubEAK7EXdf0c7bxGw=.68d5e9db-dbba-4cf2-81b7-83094410e950@github.com>
Message-ID: <vRCuNVXJuZBUkHMlyBvC7RO6OEC6v1vhbfTu6F4kic8=.238dfe2b-32f6-4eef-848f-538dc63f9b28@github.com>

On Wed, 7 Jun 2023 12:56:18 GMT, Alan Bateman <alanb at openjdk.org> 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:   </change>
> 
> 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

From sspitsyn at openjdk.org  Wed Jun  7 13:20:02 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 7 Jun 2023 13:20:02 GMT
Subject: Integrated: 8307153: JVMTI GetThreadState on carrier should return
 STATE_WAITING
In-Reply-To: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>
References: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>
Message-ID: <rDtoW7KfHie4-8zmjT8wkrSqQFZbah_tfVtiDmiuYGA=.343dbb9e-3cc5-4b5b-a2cf-847f675d79c1@github.com>

On Sat, 3 Jun 2023 10:53:04 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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 <sspitsyn at openjdk.org>
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

From alanb at openjdk.org  Wed Jun  7 13:27:06 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Jun 2023 13:27:06 GMT
Subject: RFR: 8307153: JVMTI GetThreadState on carrier should return
 STATE_WAITING [v6]
In-Reply-To: <ZCtBzX0ve4-qwkfC8HKRdztiTLrJO2VZQdac-UM0ht4=.514c4bd1-51e0-4ae6-8668-3386a79b37a2@github.com>
References: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>
 <ZCtBzX0ve4-qwkfC8HKRdztiTLrJO2VZQdac-UM0ht4=.514c4bd1-51e0-4ae6-8668-3386a79b37a2@github.com>
Message-ID: <V7OmRb9AfYiPL5b6Ta_49IQLy6tinRmM8-ysgYgbcUU=.66631d75-95aa-4163-bc07-80be3707e63d@github.com>

On Wed, 7 Jun 2023 11:48:19 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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

From sspitsyn at openjdk.org  Wed Jun  7 13:36:06 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 7 Jun 2023 13:36:06 GMT
Subject: RFR: 8307153: JVMTI GetThreadState on carrier should return
 STATE_WAITING [v6]
In-Reply-To: <V7OmRb9AfYiPL5b6Ta_49IQLy6tinRmM8-ysgYgbcUU=.66631d75-95aa-4163-bc07-80be3707e63d@github.com>
References: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>
 <ZCtBzX0ve4-qwkfC8HKRdztiTLrJO2VZQdac-UM0ht4=.514c4bd1-51e0-4ae6-8668-3386a79b37a2@github.com>
 <V7OmRb9AfYiPL5b6Ta_49IQLy6tinRmM8-ysgYgbcUU=.66631d75-95aa-4163-bc07-80be3707e63d@github.com>
Message-ID: <AKbTu2TVQFMMSRVskAakUhU_ShqCP1kMJBKCMriKa3I=.8f9ed4b5-4973-4ce8-9b73-3c000c1a5258@github.com>

On Wed, 7 Jun 2023 13:24:32 GMT, Alan Bateman <alanb at openjdk.org> 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

From kdnilsen at openjdk.org  Wed Jun  7 13:37:44 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 7 Jun 2023 13:37:44 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v12]
In-Reply-To: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
Message-ID: <HEhm9VpnzZMqrNKHnTZS_fb-gmaMHKIzd_sWjZKTUM0=.a613d1fd-18cf-45f5-a580-4303ddef0992@github.com>

> 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&pr=14185&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14185&range=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

From kdnilsen at openjdk.org  Wed Jun  7 13:37:57 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 7 Jun 2023 13:37:57 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v9]
In-Reply-To: <ll2F5iewKHlhTTAWwK3t3HfUOYL38YcIOiRHQPKAYpM=.b678a515-a5f1-4ab4-927d-a62a9d858b17@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <5tvdtUZnFnmoUyyVFYoOZm_KtVSzjfzBI7aPXpCpgVw=.2c09ff27-4004-44f3-b86d-a88d2f43a2a8@github.com>
 <ll2F5iewKHlhTTAWwK3t3HfUOYL38YcIOiRHQPKAYpM=.b678a515-a5f1-4ab4-927d-a62a9d858b17@github.com>
Message-ID: <LV5Hr6SAqsOrU6r9uHD34UB1hBaqHf9JEGiHIBgcEC8=.47290fe3-dc50-4684-9f82-dab4f8bd4d94@github.com>

On Wed, 7 Jun 2023 07:54:17 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> 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

From duke at openjdk.org  Wed Jun  7 13:46:05 2023
From: duke at openjdk.org (JoKern65)
Date: Wed, 7 Jun 2023 13:46:05 GMT
Subject: Integrated: JDK-8309225: Fix xlc17 clang 15 warnings in security and
 servicability
In-Reply-To: <TVjM9BfpfntsYda5nA4AcZazR-O8Mjl1SyTFu-Bmtpo=.d407a6a1-a865-49ea-8a58-deba1ba11d0c@github.com>
References: <TVjM9BfpfntsYda5nA4AcZazR-O8Mjl1SyTFu-Bmtpo=.d407a6a1-a865-49ea-8a58-deba1ba11d0c@github.com>
Message-ID: <A-zxy4JvObGw8m25XfW1pacTBHxZhy1eHArVX_3Ealc=.dcd56852-c1fb-4452-bf05-8c85dd068a45@github.com>

On Fri, 2 Jun 2023 10:19:53 GMT, JoKern65 <duke at openjdk.org> 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 <Joachim.kern at sap.com>
Committer: Martin Doerr <mdoerr at openjdk.org>
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

From duke at openjdk.org  Wed Jun  7 13:52:54 2023
From: duke at openjdk.org (JoKern65)
Date: Wed, 7 Jun 2023 13:52:54 GMT
Subject: RFR: JDK-8309462:
 vmTestbase/nsk/jvmti/RunAgentThread/agentthr001/TestDescription.java crashing
 due to empty while loop
In-Reply-To: <XLSnFyCggsHJL-YGgwO1icLhcDc-gFX98AR3NR8wB0Y=.024c3b61-79d2-42a6-a38e-517233c23091@github.com>
References: <XLSnFyCggsHJL-YGgwO1icLhcDc-gFX98AR3NR8wB0Y=.024c3b61-79d2-42a6-a38e-517233c23091@github.com>
Message-ID: <phudBwQEFpOgg2iALCmNXz2iTGfeWE5Iqm9YTmepyFc=.33b3aca7-f95d-481c-9aba-d113ba511411@github.com>

On Tue, 6 Jun 2023 09:51:09 GMT, JoKern65 <duke at openjdk.org> 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 <unistd.h>`
> `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

From duke at openjdk.org  Wed Jun  7 14:01:33 2023
From: duke at openjdk.org (JoKern65)
Date: Wed, 7 Jun 2023 14:01:33 GMT
Subject: RFR: JDK-8309462:
 vmTestbase/nsk/jvmti/RunAgentThread/agentthr001/TestDescription.java crashing
 due to empty while loop [v2]
In-Reply-To: <XLSnFyCggsHJL-YGgwO1icLhcDc-gFX98AR3NR8wB0Y=.024c3b61-79d2-42a6-a38e-517233c23091@github.com>
References: <XLSnFyCggsHJL-YGgwO1icLhcDc-gFX98AR3NR8wB0Y=.024c3b61-79d2-42a6-a38e-517233c23091@github.com>
Message-ID: <JfcbVbfbFoGs7zqh8LbjyFVOAsjjajTL_Qfj1KOamvM=.d969c7ff-a740-453e-ac9d-98d65cdcab9f@github.com>

> 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 <unistd.h>`
> `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&pr=14330&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14330&range=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

From duke at openjdk.org  Wed Jun  7 14:04:14 2023
From: duke at openjdk.org (JoKern65)
Date: Wed, 7 Jun 2023 14:04:14 GMT
Subject: RFR: JDK-8309462:
 vmTestbase/nsk/jvmti/RunAgentThread/agentthr001/TestDescription.java crashing
 due to empty while loop [v3]
In-Reply-To: <XLSnFyCggsHJL-YGgwO1icLhcDc-gFX98AR3NR8wB0Y=.024c3b61-79d2-42a6-a38e-517233c23091@github.com>
References: <XLSnFyCggsHJL-YGgwO1icLhcDc-gFX98AR3NR8wB0Y=.024c3b61-79d2-42a6-a38e-517233c23091@github.com>
Message-ID: <-A8xf1yGnRBGrKQ069bz9f60DUOncpaoGSnEbNsGA34=.a754f901-62e0-41cc-9a20-be3ca708a27f@github.com>

> 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 <unistd.h>`
> `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&pr=14330&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14330&range=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

From kdnilsen at openjdk.org  Wed Jun  7 14:09:23 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 7 Jun 2023 14:09:23 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v12]
In-Reply-To: <HEhm9VpnzZMqrNKHnTZS_fb-gmaMHKIzd_sWjZKTUM0=.a613d1fd-18cf-45f5-a580-4303ddef0992@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <HEhm9VpnzZMqrNKHnTZS_fb-gmaMHKIzd_sWjZKTUM0=.a613d1fd-18cf-45f5-a580-4303ddef0992@github.com>
Message-ID: <ON6QyH2Abl_JhL-0-xz03bhyV296gGX07ARGlQUuM8g=.5b5a8eec-6a4a-48c9-b8f4-4c3f20b51155@github.com>

On Wed, 7 Jun 2023 13:37:44 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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

From kdnilsen at openjdk.org  Wed Jun  7 14:09:25 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 7 Jun 2023 14:09:25 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v9]
In-Reply-To: <ll2F5iewKHlhTTAWwK3t3HfUOYL38YcIOiRHQPKAYpM=.b678a515-a5f1-4ab4-927d-a62a9d858b17@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <5tvdtUZnFnmoUyyVFYoOZm_KtVSzjfzBI7aPXpCpgVw=.2c09ff27-4004-44f3-b86d-a88d2f43a2a8@github.com>
 <ll2F5iewKHlhTTAWwK3t3HfUOYL38YcIOiRHQPKAYpM=.b678a515-a5f1-4ab4-927d-a62a9d858b17@github.com>
Message-ID: <4oGdxjol_Xzl_3bE1LgSwsvWzfNgt7yli7dqVBc5yb8=.bab01852-5037-4b19-bc81-f67b6dd13611@github.com>

On Wed, 7 Jun 2023 07:52:35 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> 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

From mdoerr at openjdk.org  Wed Jun  7 14:10:58 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 7 Jun 2023 14:10:58 GMT
Subject: RFR: JDK-8309462:
 vmTestbase/nsk/jvmti/RunAgentThread/agentthr001/TestDescription.java crashing
 due to empty while loop [v3]
In-Reply-To: <-A8xf1yGnRBGrKQ069bz9f60DUOncpaoGSnEbNsGA34=.a754f901-62e0-41cc-9a20-be3ca708a27f@github.com>
References: <XLSnFyCggsHJL-YGgwO1icLhcDc-gFX98AR3NR8wB0Y=.024c3b61-79d2-42a6-a38e-517233c23091@github.com>
 <-A8xf1yGnRBGrKQ069bz9f60DUOncpaoGSnEbNsGA34=.a754f901-62e0-41cc-9a20-be3ca708a27f@github.com>
Message-ID: <kqUN4CZZF2_7PATQ4VSuh80Rk8MOPVxQdbtv3JpYmvw=.6125213b-57ce-4936-bcb8-30f9c0d355a2@github.com>

On Wed, 7 Jun 2023 14:04:14 GMT, JoKern65 <duke at openjdk.org> 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 <unistd.h>`
>> `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

From kdnilsen at openjdk.org  Wed Jun  7 14:38:29 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 7 Jun 2023 14:38:29 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v9]
In-Reply-To: <oYom4NtPJPDwG1ZxdCcc8xh0ZUdTff-IzrfWgi-rHwE=.5a0c0bfc-2fbd-4589-9bb5-114877add85b@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <5tvdtUZnFnmoUyyVFYoOZm_KtVSzjfzBI7aPXpCpgVw=.2c09ff27-4004-44f3-b86d-a88d2f43a2a8@github.com>
 <oYom4NtPJPDwG1ZxdCcc8xh0ZUdTff-IzrfWgi-rHwE=.5a0c0bfc-2fbd-4589-9bb5-114877add85b@github.com>
Message-ID: <vzI2vxzMp32FrCTYMlh_sOK5efm2wyfrOdV10HGtDEs=.32e522b5-6d1b-4a71-858e-b86b02aa6db1@github.com>

On Wed, 7 Jun 2023 07:34:44 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> 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

From dcubed at openjdk.org  Wed Jun  7 14:42:04 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 7 Jun 2023 14:42:04 GMT
Subject: RFR: 8309614: [BACKOUT] JDK-8307153 JVMTI GetThreadState on carrier
 should return STATE_WAITING
Message-ID: <uDblLqnCynMhZgCu6xizbmInDea_SXDJTv8rY5saCcs=.321894e8-65f0-43de-ac30-8688c9eafe4e@github.com>

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&pr=14359&range=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

From dcubed at openjdk.org  Wed Jun  7 14:44:10 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 7 Jun 2023 14:44:10 GMT
Subject: RFR: 8307153: JVMTI GetThreadState on carrier should return
 STATE_WAITING [v6]
In-Reply-To: <ZCtBzX0ve4-qwkfC8HKRdztiTLrJO2VZQdac-UM0ht4=.514c4bd1-51e0-4ae6-8668-3386a79b37a2@github.com>
References: <NPcZWlSClbuxMB8gc490OiOOq9fqf9O7-v4QX065HrQ=.7feceff2-7fc3-42e2-a2e8-c560d2eecfd0@github.com>
 <ZCtBzX0ve4-qwkfC8HKRdztiTLrJO2VZQdac-UM0ht4=.514c4bd1-51e0-4ae6-8668-3386a79b37a2@github.com>
Message-ID: <89TTwIzHO2gB9XwBttdaPsa09Y00QHzAGZ3YG3IG2Z8=.8d977a17-207c-4728-b6d2-f3d7c12aa13c@github.com>

On Wed, 7 Jun 2023 11:48:19 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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

From azvegint at openjdk.org  Wed Jun  7 14:46:55 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 7 Jun 2023 14:46:55 GMT
Subject: RFR: 8309614: [BACKOUT] JDK-8307153 JVMTI GetThreadState on
 carrier should return STATE_WAITING
In-Reply-To: <uDblLqnCynMhZgCu6xizbmInDea_SXDJTv8rY5saCcs=.321894e8-65f0-43de-ac30-8688c9eafe4e@github.com>
References: <uDblLqnCynMhZgCu6xizbmInDea_SXDJTv8rY5saCcs=.321894e8-65f0-43de-ac30-8688c9eafe4e@github.com>
Message-ID: <_Tr0APesEl_SWoQt5z76pgNj9x6BVD2Nh1pQhaIysIo=.66d68136-15e5-4aad-8992-4207c62f000d@github.com>

On Wed, 7 Jun 2023 14:33:51 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> This reverts commit 177e8327d685444d63235567f2a9bde0ec3d51cf.

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14359#pullrequestreview-1467877421

From kdnilsen at openjdk.org  Wed Jun  7 14:47:13 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 7 Jun 2023 14:47:13 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v13]
In-Reply-To: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
Message-ID: <G3lSgtOjBwIHxdPICoMt4OwmDZvlAJQfagWrg0_B3CI=.fa704b8d-5830-441b-8910-881c942cfca5@github.com>

> 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&pr=14185&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14185&range=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

From dcubed at openjdk.org  Wed Jun  7 14:50:55 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 7 Jun 2023 14:50:55 GMT
Subject: RFR: 8309614: [BACKOUT] JDK-8307153 JVMTI GetThreadState on
 carrier should return STATE_WAITING
In-Reply-To: <_Tr0APesEl_SWoQt5z76pgNj9x6BVD2Nh1pQhaIysIo=.66d68136-15e5-4aad-8992-4207c62f000d@github.com>
References: <uDblLqnCynMhZgCu6xizbmInDea_SXDJTv8rY5saCcs=.321894e8-65f0-43de-ac30-8688c9eafe4e@github.com>
 <_Tr0APesEl_SWoQt5z76pgNj9x6BVD2Nh1pQhaIysIo=.66d68136-15e5-4aad-8992-4207c62f000d@github.com>
Message-ID: <HWzDTOSIsrdezRjsytAllOh2ldK-Hc3uTaFaLS1SoqQ=.ba092d56-c4f8-4c0d-9de0-539678992917@github.com>

On Wed, 7 Jun 2023 14:43:45 GMT, Alexander Zvegintsev <azvegint at openjdk.org> 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

From clanger at openjdk.org  Wed Jun  7 14:54:57 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 7 Jun 2023 14:54:57 GMT
Subject: RFR: JDK-8309462:
 vmTestbase/nsk/jvmti/RunAgentThread/agentthr001/TestDescription.java crashing
 due to empty while loop [v3]
In-Reply-To: <-A8xf1yGnRBGrKQ069bz9f60DUOncpaoGSnEbNsGA34=.a754f901-62e0-41cc-9a20-be3ca708a27f@github.com>
References: <XLSnFyCggsHJL-YGgwO1icLhcDc-gFX98AR3NR8wB0Y=.024c3b61-79d2-42a6-a38e-517233c23091@github.com>
 <-A8xf1yGnRBGrKQ069bz9f60DUOncpaoGSnEbNsGA34=.a754f901-62e0-41cc-9a20-be3ca708a27f@github.com>
Message-ID: <VqJm1nLgZArhY49RZP9EeLpd4oGXRM3nzaK9wssqyi8=.208a1035-6589-4930-8609-5fce1f6049d7@github.com>

On Wed, 7 Jun 2023 14:04:14 GMT, JoKern65 <duke at openjdk.org> 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 <unistd.h>`
>> `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

From kdnilsen at openjdk.org  Wed Jun  7 15:02:34 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 7 Jun 2023 15:02:34 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v14]
In-Reply-To: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
Message-ID: <NUmJ4e48nrYHv16ExKKg7twgeY2daOkclktliwGPCvM=.2dab8d3d-bcc6-4bca-bcba-782d83bed882@github.com>

> 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&pr=14185&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14185&range=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

From dcubed at openjdk.org  Wed Jun  7 15:07:56 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 7 Jun 2023 15:07:56 GMT
Subject: RFR: 8309614: [BACKOUT] JDK-8307153 JVMTI GetThreadState on
 carrier should return STATE_WAITING
In-Reply-To: <uDblLqnCynMhZgCu6xizbmInDea_SXDJTv8rY5saCcs=.321894e8-65f0-43de-ac30-8688c9eafe4e@github.com>
References: <uDblLqnCynMhZgCu6xizbmInDea_SXDJTv8rY5saCcs=.321894e8-65f0-43de-ac30-8688c9eafe4e@github.com>
Message-ID: <XsW2XGOiJ_K-gTAbrB_IZSDmD1ZbqHGEFH6imF_bjJM=.d32d7028-a378-4884-8ff7-c5820371a53b@github.com>

On Wed, 7 Jun 2023 14:33:51 GMT, Daniel D. Daugherty <dcubed at openjdk.org> 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

From dcubed at openjdk.org  Wed Jun  7 15:15:55 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 7 Jun 2023 15:15:55 GMT
Subject: RFR: 8309614: [BACKOUT] JDK-8307153 JVMTI GetThreadState on
 carrier should return STATE_WAITING
In-Reply-To: <uDblLqnCynMhZgCu6xizbmInDea_SXDJTv8rY5saCcs=.321894e8-65f0-43de-ac30-8688c9eafe4e@github.com>
References: <uDblLqnCynMhZgCu6xizbmInDea_SXDJTv8rY5saCcs=.321894e8-65f0-43de-ac30-8688c9eafe4e@github.com>
Message-ID: <9G1JkknuhUm2cDiBnCfkEU3pbTN2a4PeHkMdUWpjmzE=.2b6ab4d8-886e-4105-b550-cd9a50f60224@github.com>

On Wed, 7 Jun 2023 14:33:51 GMT, Daniel D. Daugherty <dcubed at openjdk.org> 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

From dcubed at openjdk.org  Wed Jun  7 15:21:04 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 7 Jun 2023 15:21:04 GMT
Subject: Integrated: 8309614: [BACKOUT] JDK-8307153 JVMTI GetThreadState on
 carrier should return STATE_WAITING
In-Reply-To: <uDblLqnCynMhZgCu6xizbmInDea_SXDJTv8rY5saCcs=.321894e8-65f0-43de-ac30-8688c9eafe4e@github.com>
References: <uDblLqnCynMhZgCu6xizbmInDea_SXDJTv8rY5saCcs=.321894e8-65f0-43de-ac30-8688c9eafe4e@github.com>
Message-ID: <K_cplqpxXkSgrZxGOKlfyU-FBV3qeGAxULc-ocaWPgo=.62b9c870-6571-4d99-986d-5b632484bdf5@github.com>

On Wed, 7 Jun 2023 14:33:51 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> This reverts commit 177e8327d685444d63235567f2a9bde0ec3d51cf.

This pull request has now been integrated.

Changeset: 33bb64f2
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
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

From dcubed at openjdk.org  Wed Jun  7 15:24:03 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 7 Jun 2023 15:24:03 GMT
Subject: RFR: 8309614: [BACKOUT] JDK-8307153 JVMTI GetThreadState on
 carrier should return STATE_WAITING
In-Reply-To: <uDblLqnCynMhZgCu6xizbmInDea_SXDJTv8rY5saCcs=.321894e8-65f0-43de-ac30-8688c9eafe4e@github.com>
References: <uDblLqnCynMhZgCu6xizbmInDea_SXDJTv8rY5saCcs=.321894e8-65f0-43de-ac30-8688c9eafe4e@github.com>
Message-ID: <MDDhJ6jXi4zjLae9Fzu5LFsLEVcvU0wACCQMmJwA1Mc=.245bc35b-63af-4523-b56c-5ed1a5346566@github.com>

On Wed, 7 Jun 2023 14:33:51 GMT, Daniel D. Daugherty <dcubed at openjdk.org> 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

From iris at openjdk.org  Wed Jun  7 15:41:55 2023
From: iris at openjdk.org (Iris Clark)
Date: Wed, 7 Jun 2023 15:41:55 GMT
Subject: RFR: 8309602: update JVMTI history table for jdk 21 [v3]
In-Reply-To: <2cVTkVoKxRkH6B_a7B6Toc6hK5IWhnwJkBX0hnP_g-0=.e169eba0-bf85-4a9c-b227-211c5315d74a@github.com>
References: <n07_y3NMnvJFFNJBV7dbuoMNlLP1cymGyYNiupbbnsg=.00eaf437-3edf-4e1b-bf5f-8136c0c1183c@github.com>
 <2cVTkVoKxRkH6B_a7B6Toc6hK5IWhnwJkBX0hnP_g-0=.e169eba0-bf85-4a9c-b227-211c5315d74a@github.com>
Message-ID: <WJ-RG1tVB99uaAV2qxug6LTL6urK4sz89qf9nPowuBM=.d477471d-880b-43fa-987d-92f107562058@github.com>

On Wed, 7 Jun 2023 13:08:00 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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

From kdnilsen at openjdk.org  Wed Jun  7 16:00:37 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 7 Jun 2023 16:00:37 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v15]
In-Reply-To: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
Message-ID: <SHpGkeoJuB0XZ6RVMvMwe8QrBxVPi3psVy9o1TVQN6w=.fbfcf160-272a-4482-9ddd-a3c59f6703f5@github.com>

> 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&pr=14185&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14185&range=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

From kdnilsen at openjdk.org  Wed Jun  7 16:51:38 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 7 Jun 2023 16:51:38 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v16]
In-Reply-To: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
Message-ID: <9vJprjFu5K2ZymOM-lzCm_IAA2pAnGBgCDAtwQ0sOvw=.47abdb57-237b-4c57-a5e1-25f11ee14a80@github.com>

> 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&pr=14185&range=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

From cjplummer at openjdk.org  Wed Jun  7 17:51:59 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 7 Jun 2023 17:51:59 GMT
Subject: RFR: 8309509:
 com/sun/jdi/RedefineNestmateAttr/TestNestmateAttr.java fails with virtual test
 thread factory
In-Reply-To: <oqLBwARuJ3rFGRCxCEdnVbvNyLP1DxCHHixj5OYEJ3Y=.462f7350-24f7-4e41-9db5-8288f6c26b6d@github.com>
References: <oqLBwARuJ3rFGRCxCEdnVbvNyLP1DxCHHixj5OYEJ3Y=.462f7350-24f7-4e41-9db5-8288f6c26b6d@github.com>
Message-ID: <T7uAYYp0vvS3OrfBoxJcO5K_rlfEIQoInXoR7AIADKU=.39052437-e646-4c02-af87-029c67d6580a@github.com>

On Tue, 6 Jun 2023 00:02:47 GMT, Chris Plummer <cjplummer at openjdk.org> 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

From cjplummer at openjdk.org  Wed Jun  7 17:51:59 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 7 Jun 2023 17:51:59 GMT
Subject: Integrated: 8309509:
 com/sun/jdi/RedefineNestmateAttr/TestNestmateAttr.java fails with virtual test
 thread factory
In-Reply-To: <oqLBwARuJ3rFGRCxCEdnVbvNyLP1DxCHHixj5OYEJ3Y=.462f7350-24f7-4e41-9db5-8288f6c26b6d@github.com>
References: <oqLBwARuJ3rFGRCxCEdnVbvNyLP1DxCHHixj5OYEJ3Y=.462f7350-24f7-4e41-9db5-8288f6c26b6d@github.com>
Message-ID: <XkCJu0weG4BHVTeeblB9FnEs6Uza4Y5hYvWN7-AMfmU=.c01f8551-3e99-4810-bb52-c8241d0fb72f@github.com>

On Tue, 6 Jun 2023 00:02:47 GMT, Chris Plummer <cjplummer at openjdk.org> 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 <cjplummer at openjdk.org>
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

From cjplummer at openjdk.org  Wed Jun  7 18:00:32 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 7 Jun 2023 18:00:32 GMT
Subject: RFR: 8309510:
 com/sun/jdi/RedefineNestmateAttr/TestNestmateAttr.java no longer needs to
 override startUp() method
In-Reply-To: <6kWHttu7fg50M_7FJ_zGVAbJl-UrWu6VfPMwyFCEUUk=.d6e1fcea-f821-4adb-92f4-217051c572e7@github.com>
References: <6kWHttu7fg50M_7FJ_zGVAbJl-UrWu6VfPMwyFCEUUk=.d6e1fcea-f821-4adb-92f4-217051c572e7@github.com>
Message-ID: <px1O9-IkFTZzpYAmNudhVHpSmG3op_8n5HWhKWGxqyI=.def478b2-56a6-4e24-896f-3986b6ec78d1@github.com>

On Tue, 6 Jun 2023 00:36:12 GMT, Chris Plummer <cjplummer at openjdk.org> 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<String> 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

From cjplummer at openjdk.org  Wed Jun  7 18:00:33 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 7 Jun 2023 18:00:33 GMT
Subject: Integrated: 8309510:
 com/sun/jdi/RedefineNestmateAttr/TestNestmateAttr.java no longer needs to
 override startUp() method
In-Reply-To: <6kWHttu7fg50M_7FJ_zGVAbJl-UrWu6VfPMwyFCEUUk=.d6e1fcea-f821-4adb-92f4-217051c572e7@github.com>
References: <6kWHttu7fg50M_7FJ_zGVAbJl-UrWu6VfPMwyFCEUUk=.d6e1fcea-f821-4adb-92f4-217051c572e7@github.com>
Message-ID: <vYxC35W0gLq2wjAc8NT7YFuPhrHTKIWXQ4ohKhEklIE=.f7edff7f-90ec-4635-a35c-38e445222fe3@github.com>

On Tue, 6 Jun 2023 00:36:12 GMT, Chris Plummer <cjplummer at openjdk.org> 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<String> 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 <cjplummer at openjdk.org>
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

From cjplummer at openjdk.org  Wed Jun  7 18:06:46 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 7 Jun 2023 18:06:46 GMT
Subject: RFR: 8309420: com/sun/jdi/StepTest.java fails with virtual thread
 wrapper
In-Reply-To: <av9ig1PwtvEjkgBDkNizeyzkLb4IDuEgMbv9ABq8vhs=.fac3313d-291f-4c81-914d-a67d14916911@github.com>
References: <av9ig1PwtvEjkgBDkNizeyzkLb4IDuEgMbv9ABq8vhs=.fac3313d-291f-4c81-914d-a67d14916911@github.com>
Message-ID: <6oxqRDdA94hwUsH4cKxHUhgXKOQV4fJYsDRZYxHN3XU=.89098067-ea69-4072-89e9-13e713a75948@github.com>

On Mon, 5 Jun 2023 04:03:57 GMT, Chris Plummer <cjplummer at openjdk.org> 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

From cjplummer at openjdk.org  Wed Jun  7 18:06:48 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 7 Jun 2023 18:06:48 GMT
Subject: Integrated: 8309420: com/sun/jdi/StepTest.java fails with virtual
 thread wrapper
In-Reply-To: <av9ig1PwtvEjkgBDkNizeyzkLb4IDuEgMbv9ABq8vhs=.fac3313d-291f-4c81-914d-a67d14916911@github.com>
References: <av9ig1PwtvEjkgBDkNizeyzkLb4IDuEgMbv9ABq8vhs=.fac3313d-291f-4c81-914d-a67d14916911@github.com>
Message-ID: <1Z9g1Q1xIykL6UragWbioCzEZY88SzoG9W15fkvCW5w=.448e1733-77fd-4746-9d43-5e128bb4630f@github.com>

On Mon, 5 Jun 2023 04:03:57 GMT, Chris Plummer <cjplummer at openjdk.org> 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 <cjplummer at openjdk.org>
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

From kdnilsen at openjdk.org  Wed Jun  7 18:21:43 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 7 Jun 2023 18:21:43 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v17]
In-Reply-To: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
Message-ID: <AQ7JahiqfbEGMyeqZPwxx_4ORLBDGrC1Mi0oxQhmlgk=.d37920fe-44cb-4975-8df3-6eb87598f6a1@github.com>

> 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&pr=14185&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14185&range=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

From stuefe at openjdk.org  Wed Jun  7 18:21:45 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 7 Jun 2023 18:21:45 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v12]
In-Reply-To: <ON6QyH2Abl_JhL-0-xz03bhyV296gGX07ARGlQUuM8g=.5b5a8eec-6a4a-48c9-b8f4-4c3f20b51155@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <HEhm9VpnzZMqrNKHnTZS_fb-gmaMHKIzd_sWjZKTUM0=.a613d1fd-18cf-45f5-a580-4303ddef0992@github.com>
 <ON6QyH2Abl_JhL-0-xz03bhyV296gGX07ARGlQUuM8g=.5b5a8eec-6a4a-48c9-b8f4-4c3f20b51155@github.com>
Message-ID: <U0DMCXy3xy3Aa3zdfZAvhwzFODdT_rcYnnRHvQFx4XU=.04712546-f3f2-49cf-b852-ddd7c43f768b@github.com>

On Wed, 7 Jun 2023 14:06:31 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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

From stuefe at openjdk.org  Wed Jun  7 18:21:48 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 7 Jun 2023 18:21:48 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v16]
In-Reply-To: <9vJprjFu5K2ZymOM-lzCm_IAA2pAnGBgCDAtwQ0sOvw=.47abdb57-237b-4c57-a5e1-25f11ee14a80@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <9vJprjFu5K2ZymOM-lzCm_IAA2pAnGBgCDAtwQ0sOvw=.47abdb57-237b-4c57-a5e1-25f11ee14a80@github.com>
Message-ID: <u2BlHDb1N1tr7NWl2xEh6JtzkEUtYLP1ZUOHMv_qrcE=.eb38cb51-8ece-4b1c-be73-9eaa075cce09@github.com>

On Wed, 7 Jun 2023 16:51:38 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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

From sspitsyn at openjdk.org  Wed Jun  7 18:51:55 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 7 Jun 2023 18:51:55 GMT
Subject: RFR: 8309612: [R[REDO] JDK-8307153 JVMTI GetThreadState on carrier
 should return STATE_WAITING
Message-ID: <2yWxf_TT2Dw2LLUa9fs8GZM-EfYIAOD-mTv1GLmg6o4=.705caff7-40a4-4dcb-862f-cebac0be68db@github.com>

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&pr=14366&range=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

From sspitsyn at openjdk.org  Wed Jun  7 19:27:05 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 7 Jun 2023 19:27:05 GMT
Subject: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier
 should return STATE_WAITING [v2]
In-Reply-To: <2yWxf_TT2Dw2LLUa9fs8GZM-EfYIAOD-mTv1GLmg6o4=.705caff7-40a4-4dcb-862f-cebac0be68db@github.com>
References: <2yWxf_TT2Dw2LLUa9fs8GZM-EfYIAOD-mTv1GLmg6o4=.705caff7-40a4-4dcb-862f-cebac0be68db@github.com>
Message-ID: <ehCsJyjhM1iP2msAHM3qisFjzxdcc-euDNfprPmm1TY=.1c1b8f5a-7b30-4c7f-8eff-edda26aada26@github.com>

> 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&pr=14366&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14366&range=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

From sspitsyn at openjdk.org  Wed Jun  7 19:32:23 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 7 Jun 2023 19:32:23 GMT
Subject: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier
 should return STATE_WAITING [v3]
In-Reply-To: <2yWxf_TT2Dw2LLUa9fs8GZM-EfYIAOD-mTv1GLmg6o4=.705caff7-40a4-4dcb-862f-cebac0be68db@github.com>
References: <2yWxf_TT2Dw2LLUa9fs8GZM-EfYIAOD-mTv1GLmg6o4=.705caff7-40a4-4dcb-862f-cebac0be68db@github.com>
Message-ID: <owYlceWnj9zw_qNV47TqhfyKXMk1m6z6eP6dpNuyETY=.3822c9e4-f112-4914-b173-76fe324fe80d@github.com>

> 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&pr=14366&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14366&range=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

From sspitsyn at openjdk.org  Wed Jun  7 20:05:45 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 7 Jun 2023 20:05:45 GMT
Subject: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier
 should return STATE_WAITING [v4]
In-Reply-To: <2yWxf_TT2Dw2LLUa9fs8GZM-EfYIAOD-mTv1GLmg6o4=.705caff7-40a4-4dcb-862f-cebac0be68db@github.com>
References: <2yWxf_TT2Dw2LLUa9fs8GZM-EfYIAOD-mTv1GLmg6o4=.705caff7-40a4-4dcb-862f-cebac0be68db@github.com>
Message-ID: <Ytu2WnAYrR-fm_wwnxbfuJv8Dvj2GQDL1eGoJZ2SrVU=.95270690-1da0-4cd0-a97a-c65ed6ba3983@github.com>

> 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&pr=14366&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14366&range=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

From cjplummer at openjdk.org  Wed Jun  7 20:15:54 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 7 Jun 2023 20:15:54 GMT
Subject: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier
 should return STATE_WAITING [v4]
In-Reply-To: <Ytu2WnAYrR-fm_wwnxbfuJv8Dvj2GQDL1eGoJZ2SrVU=.95270690-1da0-4cd0-a97a-c65ed6ba3983@github.com>
References: <2yWxf_TT2Dw2LLUa9fs8GZM-EfYIAOD-mTv1GLmg6o4=.705caff7-40a4-4dcb-862f-cebac0be68db@github.com>
 <Ytu2WnAYrR-fm_wwnxbfuJv8Dvj2GQDL1eGoJZ2SrVU=.95270690-1da0-4cd0-a97a-c65ed6ba3983@github.com>
Message-ID: <a2HKu8s1cU77ztHsAhjOhITfKG6huNQDTpsMA736hAA=.d3f6ae1d-acf1-45f7-b0f5-fcb06da8de06@github.com>

On Wed, 7 Jun 2023 20:05:45 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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 <jt,thr_obj> 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

From kdnilsen at openjdk.org  Wed Jun  7 21:07:39 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 7 Jun 2023 21:07:39 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v17]
In-Reply-To: <AQ7JahiqfbEGMyeqZPwxx_4ORLBDGrC1Mi0oxQhmlgk=.d37920fe-44cb-4975-8df3-6eb87598f6a1@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <AQ7JahiqfbEGMyeqZPwxx_4ORLBDGrC1Mi0oxQhmlgk=.d37920fe-44cb-4975-8df3-6eb87598f6a1@github.com>
Message-ID: <HJIK3lzM529ykBDReoHTqNgNSXEwhAE2JfadpV8iSEk=.a4f1a8e2-8290-4102-a236-9a48e8b254f9@github.com>

On Wed, 7 Jun 2023 18:21:43 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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

From kdnilsen at openjdk.org  Wed Jun  7 21:07:41 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 7 Jun 2023 21:07:41 GMT
Subject: Withdrawn: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental)
In-Reply-To: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
Message-ID: <bP94rj1Mkb3ISFlRfPerA6S2Xi0zMypnIMRYB6ZkV_k=.a32617bd-5b48-4612-884c-a6e715e9940a@github.com>

On Fri, 26 May 2023 20:46:29 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> 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

From sspitsyn at openjdk.org  Wed Jun  7 21:22:41 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 7 Jun 2023 21:22:41 GMT
Subject: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier
 should return STATE_WAITING [v5]
In-Reply-To: <2yWxf_TT2Dw2LLUa9fs8GZM-EfYIAOD-mTv1GLmg6o4=.705caff7-40a4-4dcb-862f-cebac0be68db@github.com>
References: <2yWxf_TT2Dw2LLUa9fs8GZM-EfYIAOD-mTv1GLmg6o4=.705caff7-40a4-4dcb-862f-cebac0be68db@github.com>
Message-ID: <aVuraF1j9jKS-qyepnnLRNYEhos_pGGuQr6AnKT1LhM=.2fd407ec-6727-48e6-bc9d-ca82d6179025@github.com>

> 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&pr=14366&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14366&range=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

From amenkov at openjdk.org  Wed Jun  7 21:22:44 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 7 Jun 2023 21:22:44 GMT
Subject: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier
 should return STATE_WAITING [v4]
In-Reply-To: <Ytu2WnAYrR-fm_wwnxbfuJv8Dvj2GQDL1eGoJZ2SrVU=.95270690-1da0-4cd0-a97a-c65ed6ba3983@github.com>
References: <2yWxf_TT2Dw2LLUa9fs8GZM-EfYIAOD-mTv1GLmg6o4=.705caff7-40a4-4dcb-862f-cebac0be68db@github.com>
 <Ytu2WnAYrR-fm_wwnxbfuJv8Dvj2GQDL1eGoJZ2SrVU=.95270690-1da0-4cd0-a97a-c65ed6ba3983@github.com>
Message-ID: <8pd-OWsWDM6RK-_X479uitxD-NNERoHXggUi4F7iemM=.229a79e8-5140-456b-80ba-2916e7dd95d9@github.com>

On Wed, 7 Jun 2023 20:05:45 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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

From sspitsyn at openjdk.org  Wed Jun  7 21:22:49 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 7 Jun 2023 21:22:49 GMT
Subject: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier
 should return STATE_WAITING [v4]
In-Reply-To: <a2HKu8s1cU77ztHsAhjOhITfKG6huNQDTpsMA736hAA=.d3f6ae1d-acf1-45f7-b0f5-fcb06da8de06@github.com>
References: <2yWxf_TT2Dw2LLUa9fs8GZM-EfYIAOD-mTv1GLmg6o4=.705caff7-40a4-4dcb-862f-cebac0be68db@github.com>
 <Ytu2WnAYrR-fm_wwnxbfuJv8Dvj2GQDL1eGoJZ2SrVU=.95270690-1da0-4cd0-a97a-c65ed6ba3983@github.com>
 <a2HKu8s1cU77ztHsAhjOhITfKG6huNQDTpsMA736hAA=.d3f6ae1d-acf1-45f7-b0f5-fcb06da8de06@github.com>
Message-ID: <CuQe10yLX8JcE8R4C-nyM3PXtWmkN77HIf42ZR8T1KY=.1b59d195-811d-42bf-8c2a-89eee73fa9d7@github.com>

On Wed, 7 Jun 2023 20:10:24 GMT, Chris Plummer <cjplummer at openjdk.org> 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 <jt,thr_obj> 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

From sspitsyn at openjdk.org  Wed Jun  7 21:57:49 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 7 Jun 2023 21:57:49 GMT
Subject: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier
 should return STATE_WAITING [v4]
In-Reply-To: <8pd-OWsWDM6RK-_X479uitxD-NNERoHXggUi4F7iemM=.229a79e8-5140-456b-80ba-2916e7dd95d9@github.com>
References: <2yWxf_TT2Dw2LLUa9fs8GZM-EfYIAOD-mTv1GLmg6o4=.705caff7-40a4-4dcb-862f-cebac0be68db@github.com>
 <Ytu2WnAYrR-fm_wwnxbfuJv8Dvj2GQDL1eGoJZ2SrVU=.95270690-1da0-4cd0-a97a-c65ed6ba3983@github.com>
 <8pd-OWsWDM6RK-_X479uitxD-NNERoHXggUi4F7iemM=.229a79e8-5140-456b-80ba-2916e7dd95d9@github.com>
Message-ID: <ZefSu_UYkpzXgX5hFJFIvf0e1cv5W2YAfdGWMaZYZuU=.1c53c003-4b84-48ff-85cb-3cd8fa2aced6@github.com>

On Wed, 7 Jun 2023 21:12:24 GMT, Alex Menkov <amenkov at openjdk.org> 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_r1222212064

From cjplummer at openjdk.org  Wed Jun  7 22:23:49 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 7 Jun 2023 22:23:49 GMT
Subject: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier
 should return STATE_WAITING [v5]
In-Reply-To: <aVuraF1j9jKS-qyepnnLRNYEhos_pGGuQr6AnKT1LhM=.2fd407ec-6727-48e6-bc9d-ca82d6179025@github.com>
References: <2yWxf_TT2Dw2LLUa9fs8GZM-EfYIAOD-mTv1GLmg6o4=.705caff7-40a4-4dcb-862f-cebac0be68db@github.com>
 <aVuraF1j9jKS-qyepnnLRNYEhos_pGGuQr6AnKT1LhM=.2fd407ec-6727-48e6-bc9d-ca82d6179025@github.com>
Message-ID: <qbvYF1R4Q3WOtkELRD5cKaQq_Lpjb6O9SmynI_vOwKg=.ab1b2bbd-4a6b-44b3-bf3d-e56d072bdc73@github.com>

On Wed, 7 Jun 2023 21:22:41 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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

From amenkov at openjdk.org  Wed Jun  7 22:45:49 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 7 Jun 2023 22:45:49 GMT
Subject: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier
 should return STATE_WAITING [v4]
In-Reply-To: <ZefSu_UYkpzXgX5hFJFIvf0e1cv5W2YAfdGWMaZYZuU=.1c53c003-4b84-48ff-85cb-3cd8fa2aced6@github.com>
References: <2yWxf_TT2Dw2LLUa9fs8GZM-EfYIAOD-mTv1GLmg6o4=.705caff7-40a4-4dcb-862f-cebac0be68db@github.com>
 <Ytu2WnAYrR-fm_wwnxbfuJv8Dvj2GQDL1eGoJZ2SrVU=.95270690-1da0-4cd0-a97a-c65ed6ba3983@github.com>
 <8pd-OWsWDM6RK-_X479uitxD-NNERoHXggUi4F7iemM=.229a79e8-5140-456b-80ba-2916e7dd95d9@github.com>
 <ZefSu_UYkpzXgX5hFJFIvf0e1cv5W2YAfdGWMaZYZuU=.1c53c003-4b84-48ff-85cb-3cd8fa2aced6@github.com>
Message-ID: <btSx8TZ6nbKRVHw5aUdr4q6nOIC7eCIcv9LSxaY4GVg=.5e932ef8-d00b-4535-a117-42290b1f458f@github.com>

On Wed, 7 Jun 2023 21:52:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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_r1222252628

From amenkov at openjdk.org  Wed Jun  7 22:51:49 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 7 Jun 2023 22:51:49 GMT
Subject: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier
 should return STATE_WAITING [v4]
In-Reply-To: <btSx8TZ6nbKRVHw5aUdr4q6nOIC7eCIcv9LSxaY4GVg=.5e932ef8-d00b-4535-a117-42290b1f458f@github.com>
References: <2yWxf_TT2Dw2LLUa9fs8GZM-EfYIAOD-mTv1GLmg6o4=.705caff7-40a4-4dcb-862f-cebac0be68db@github.com>
 <Ytu2WnAYrR-fm_wwnxbfuJv8Dvj2GQDL1eGoJZ2SrVU=.95270690-1da0-4cd0-a97a-c65ed6ba3983@github.com>
 <8pd-OWsWDM6RK-_X479uitxD-NNERoHXggUi4F7iemM=.229a79e8-5140-456b-80ba-2916e7dd95d9@github.com>
 <ZefSu_UYkpzXgX5hFJFIvf0e1cv5W2YAfdGWMaZYZuU=.1c53c003-4b84-48ff-85cb-3cd8fa2aced6@github.com>
 <btSx8TZ6nbKRVHw5aUdr4q6nOIC7eCIcv9LSxaY4GVg=.5e932ef8-d00b-4535-a117-42290b1f458f@github.com>
Message-ID: <_52Zqcx-rftOA6EzeCRNEcUPBNI-fK3nvYQJ4TItudM=.00584b6b-f4a8-486a-b0c4-40d77bca5f2b@github.com>

On Wed, 7 Jun 2023 22:42:49 GMT, Alex Menkov <amenkov at openjdk.org> 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_r1222255498

From sspitsyn at openjdk.org  Wed Jun  7 23:11:48 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 7 Jun 2023 23:11:48 GMT
Subject: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier
 should return STATE_WAITING [v4]
In-Reply-To: <_52Zqcx-rftOA6EzeCRNEcUPBNI-fK3nvYQJ4TItudM=.00584b6b-f4a8-486a-b0c4-40d77bca5f2b@github.com>
References: <2yWxf_TT2Dw2LLUa9fs8GZM-EfYIAOD-mTv1GLmg6o4=.705caff7-40a4-4dcb-862f-cebac0be68db@github.com>
 <Ytu2WnAYrR-fm_wwnxbfuJv8Dvj2GQDL1eGoJZ2SrVU=.95270690-1da0-4cd0-a97a-c65ed6ba3983@github.com>
 <8pd-OWsWDM6RK-_X479uitxD-NNERoHXggUi4F7iemM=.229a79e8-5140-456b-80ba-2916e7dd95d9@github.com>
 <ZefSu_UYkpzXgX5hFJFIvf0e1cv5W2YAfdGWMaZYZuU=.1c53c003-4b84-48ff-85cb-3cd8fa2aced6@github.com>
 <btSx8TZ6nbKRVHw5aUdr4q6nOIC7eCIcv9LSxaY4GVg=.5e932ef8-d00b-4535-a117-42290b1f458f@github.com>
 <_52Zqcx-rftOA6EzeCRNEcUPBNI-fK3nvYQJ4TItudM=.00584b6b-f4a8-486a-b0c4-40d77bca5f2b@github.com>
Message-ID: <aHDr92oHMRPJubJTAe0dGrRF2ghU9NV51pYvb-Zoyww=.005fcce8-015b-4887-9218-bca276b0d0d9@github.com>

On Wed, 7 Jun 2023 22:48:47 GMT, Alex Menkov <amenkov at openjdk.org> 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_r1222268031

From cjplummer at openjdk.org  Wed Jun  7 23:23:55 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 7 Jun 2023 23:23:55 GMT
Subject: RFR: 8232839: JDI AfterThreadDeathTest.java failed due to
 "FAILED: Did not get expected IllegalThreadStateException on a
 StepRequest.enable()"
Message-ID: <m1pRv9k7_76AZd_GEgPWd3YTrKJuDi_EClmi7s-vNJs=.61e06dcc-7e8f-4683-bebd-3c9305c308e4@github.com>

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&pr=14372&range=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

From sspitsyn at openjdk.org  Thu Jun  8 01:42:10 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 8 Jun 2023 01:42:10 GMT
Subject: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier
 should return STATE_WAITING [v6]
In-Reply-To: <2yWxf_TT2Dw2LLUa9fs8GZM-EfYIAOD-mTv1GLmg6o4=.705caff7-40a4-4dcb-862f-cebac0be68db@github.com>
References: <2yWxf_TT2Dw2LLUa9fs8GZM-EfYIAOD-mTv1GLmg6o4=.705caff7-40a4-4dcb-862f-cebac0be68db@github.com>
Message-ID: <EsD9Wc5sp6cVd6EgqH6qI0umSVAQRbVw1ls2D5bhMhU=.5ff76185-0ef4-4a52-8aab-340fee00b285@github.com>

> 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&pr=14366&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14366&range=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

From sspitsyn at openjdk.org  Thu Jun  8 01:42:25 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 8 Jun 2023 01:42:25 GMT
Subject: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier
 should return STATE_WAITING [v4]
In-Reply-To: <aHDr92oHMRPJubJTAe0dGrRF2ghU9NV51pYvb-Zoyww=.005fcce8-015b-4887-9218-bca276b0d0d9@github.com>
References: <2yWxf_TT2Dw2LLUa9fs8GZM-EfYIAOD-mTv1GLmg6o4=.705caff7-40a4-4dcb-862f-cebac0be68db@github.com>
 <Ytu2WnAYrR-fm_wwnxbfuJv8Dvj2GQDL1eGoJZ2SrVU=.95270690-1da0-4cd0-a97a-c65ed6ba3983@github.com>
 <8pd-OWsWDM6RK-_X479uitxD-NNERoHXggUi4F7iemM=.229a79e8-5140-456b-80ba-2916e7dd95d9@github.com>
 <ZefSu_UYkpzXgX5hFJFIvf0e1cv5W2YAfdGWMaZYZuU=.1c53c003-4b84-48ff-85cb-3cd8fa2aced6@github.com>
 <btSx8TZ6nbKRVHw5aUdr4q6nOIC7eCIcv9LSxaY4GVg=.5e932ef8-d00b-4535-a117-42290b1f458f@github.com>
 <_52Zqcx-rftOA6EzeCRNEcUPBNI-fK3nvYQJ4TItudM=.00584b6b-f4a8-486a-b0c4-40d77bca5f2b@github.com>
 <aHDr92oHMRPJubJTAe0dGrRF2ghU9NV51pYvb-Zoyww=.005fcce8-015b-4887-9218-bca276b0d0d9@github.com>
Message-ID: <wvdY9nzY-oc_mFfvcgu_QG1eMW0R8tiwsDs31SshE80=.6ba027d8-8697-4032-94b6-d2833e2b08e6@github.com>

On Wed, 7 Jun 2023 23:08:52 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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

From dholmes at openjdk.org  Thu Jun  8 02:09:48 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 8 Jun 2023 02:09:48 GMT
Subject: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier
 should return STATE_WAITING [v4]
In-Reply-To: <wvdY9nzY-oc_mFfvcgu_QG1eMW0R8tiwsDs31SshE80=.6ba027d8-8697-4032-94b6-d2833e2b08e6@github.com>
References: <2yWxf_TT2Dw2LLUa9fs8GZM-EfYIAOD-mTv1GLmg6o4=.705caff7-40a4-4dcb-862f-cebac0be68db@github.com>
 <Ytu2WnAYrR-fm_wwnxbfuJv8Dvj2GQDL1eGoJZ2SrVU=.95270690-1da0-4cd0-a97a-c65ed6ba3983@github.com>
 <8pd-OWsWDM6RK-_X479uitxD-NNERoHXggUi4F7iemM=.229a79e8-5140-456b-80ba-2916e7dd95d9@github.com>
 <ZefSu_UYkpzXgX5hFJFIvf0e1cv5W2YAfdGWMaZYZuU=.1c53c003-4b84-48ff-85cb-3cd8fa2aced6@github.com>
 <btSx8TZ6nbKRVHw5aUdr4q6nOIC7eCIcv9LSxaY4GVg=.5e932ef8-d00b-4535-a117-42290b1f458f@github.com>
 <_52Zqcx-rftOA6EzeCRNEcUPBNI-fK3nvYQJ4TItudM=.00584b6b-f4a8-486a-b0c4-40d77bca5f2b@github.com>
 <aHDr92oHMRPJubJTAe0dGrRF2ghU9NV51pYvb-Zoyww=.005fcce8-015b-4887-9218-bca276b0d0d9@github.com>
 <wvdY9nzY-oc_mFfvcgu_QG1eMW0R8tiwsDs31SshE80=.6ba027d8-8697-4032-94b6-d2833e2b08e6@github.com>
Message-ID: <fL_OU_j4Qng34fuvED-PquCVdLfXq28Pb5oDl84RDQs=.2d3a75e4-e090-4d5a-a9be-fae1e638fe5b@github.com>

On Thu, 8 Jun 2023 01:40:06 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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

From sspitsyn at openjdk.org  Thu Jun  8 03:39:47 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 8 Jun 2023 03:39:47 GMT
Subject: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier
 should return STATE_WAITING [v4]
In-Reply-To: <fL_OU_j4Qng34fuvED-PquCVdLfXq28Pb5oDl84RDQs=.2d3a75e4-e090-4d5a-a9be-fae1e638fe5b@github.com>
References: <2yWxf_TT2Dw2LLUa9fs8GZM-EfYIAOD-mTv1GLmg6o4=.705caff7-40a4-4dcb-862f-cebac0be68db@github.com>
 <Ytu2WnAYrR-fm_wwnxbfuJv8Dvj2GQDL1eGoJZ2SrVU=.95270690-1da0-4cd0-a97a-c65ed6ba3983@github.com>
 <8pd-OWsWDM6RK-_X479uitxD-NNERoHXggUi4F7iemM=.229a79e8-5140-456b-80ba-2916e7dd95d9@github.com>
 <ZefSu_UYkpzXgX5hFJFIvf0e1cv5W2YAfdGWMaZYZuU=.1c53c003-4b84-48ff-85cb-3cd8fa2aced6@github.com>
 <btSx8TZ6nbKRVHw5aUdr4q6nOIC7eCIcv9LSxaY4GVg=.5e932ef8-d00b-4535-a117-42290b1f458f@github.com>
 <_52Zqcx-rftOA6EzeCRNEcUPBNI-fK3nvYQJ4TItudM=.00584b6b-f4a8-486a-b0c4-40d77bca5f2b@github.com>
 <aHDr92oHMRPJubJTAe0dGrRF2ghU9NV51pYvb-Zoyww=.005fcce8-015b-4887-9218-bca276b0d0d9@github.com>
 <wvdY9nzY-oc_mFfvcgu_QG1eMW0R8tiwsDs31SshE80=.6ba027d8-8697-4032-94b6-d2833e2b08e6@github.com>
 <fL_OU_j4Qng34fuvED-PquCVdLfXq28Pb5oDl84RDQs=.2d3a75e4-e090-4d5a-a9be-fae1e638fe5b@github.com>
Message-ID: <qOMuoVNdwPFRfg1wUGqttP1qdRTuRuWrwIBvJ8CSVOE=.e01ed1f1-71ba-4ea4-a074-966e558769d3@github.com>

On Thu, 8 Jun 2023 02:07:00 GMT, David Holmes <dholmes at openjdk.org> 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

From sspitsyn at openjdk.org  Thu Jun  8 04:01:56 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 8 Jun 2023 04:01:56 GMT
Subject: RFR: 8309602: update JVMTI history table for jdk 21 [v4]
In-Reply-To: <n07_y3NMnvJFFNJBV7dbuoMNlLP1cymGyYNiupbbnsg=.00eaf437-3edf-4e1b-bf5f-8136c0c1183c@github.com>
References: <n07_y3NMnvJFFNJBV7dbuoMNlLP1cymGyYNiupbbnsg=.00eaf437-3edf-4e1b-bf5f-8136c0c1183c@github.com>
Message-ID: <7xXMXXSeQLwosyHqOBA9N6cIKIIzHRfGTOVNxYLcMOY=.4a7ce215-bf6b-4659-a502-fb001293a5c7@github.com>

> 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&pr=14352&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14352&range=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

From sspitsyn at openjdk.org  Thu Jun  8 04:06:55 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 8 Jun 2023 04:06:55 GMT
Subject: RFR: 8309602: update JVMTI history table for jdk 21 [v4]
In-Reply-To: <7xXMXXSeQLwosyHqOBA9N6cIKIIzHRfGTOVNxYLcMOY=.4a7ce215-bf6b-4659-a502-fb001293a5c7@github.com>
References: <n07_y3NMnvJFFNJBV7dbuoMNlLP1cymGyYNiupbbnsg=.00eaf437-3edf-4e1b-bf5f-8136c0c1183c@github.com>
 <7xXMXXSeQLwosyHqOBA9N6cIKIIzHRfGTOVNxYLcMOY=.4a7ce215-bf6b-4659-a502-fb001293a5c7@github.com>
Message-ID: <CUWQz6pryCAKkieqWN3LTjmt0l-UhF-oRSP8JCuTJfk=.0c637fb8-d33f-4c7a-9556-f18051c8b001@github.com>

On Thu, 8 Jun 2023 04:01:56 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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

From sspitsyn at openjdk.org  Thu Jun  8 04:06:57 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 8 Jun 2023 04:06:57 GMT
Subject: Integrated: 8309602: update JVMTI history table for jdk 21
In-Reply-To: <n07_y3NMnvJFFNJBV7dbuoMNlLP1cymGyYNiupbbnsg=.00eaf437-3edf-4e1b-bf5f-8136c0c1183c@github.com>
References: <n07_y3NMnvJFFNJBV7dbuoMNlLP1cymGyYNiupbbnsg=.00eaf437-3edf-4e1b-bf5f-8136c0c1183c@github.com>
Message-ID: <2z5JUAtnKoIy2wAx3tSYZP_SYkRlvmEm334SnqUzmxI=.5886d218-223f-4a3d-902a-5b92721b20d1@github.com>

On Wed, 7 Jun 2023 12:32:14 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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 <sspitsyn at openjdk.org>
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

From dholmes at openjdk.org  Thu Jun  8 04:32:48 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 8 Jun 2023 04:32:48 GMT
Subject: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier
 should return STATE_WAITING [v4]
In-Reply-To: <qOMuoVNdwPFRfg1wUGqttP1qdRTuRuWrwIBvJ8CSVOE=.e01ed1f1-71ba-4ea4-a074-966e558769d3@github.com>
References: <2yWxf_TT2Dw2LLUa9fs8GZM-EfYIAOD-mTv1GLmg6o4=.705caff7-40a4-4dcb-862f-cebac0be68db@github.com>
 <Ytu2WnAYrR-fm_wwnxbfuJv8Dvj2GQDL1eGoJZ2SrVU=.95270690-1da0-4cd0-a97a-c65ed6ba3983@github.com>
 <8pd-OWsWDM6RK-_X479uitxD-NNERoHXggUi4F7iemM=.229a79e8-5140-456b-80ba-2916e7dd95d9@github.com>
 <ZefSu_UYkpzXgX5hFJFIvf0e1cv5W2YAfdGWMaZYZuU=.1c53c003-4b84-48ff-85cb-3cd8fa2aced6@github.com>
 <btSx8TZ6nbKRVHw5aUdr4q6nOIC7eCIcv9LSxaY4GVg=.5e932ef8-d00b-4535-a117-42290b1f458f@github.com>
 <_52Zqcx-rftOA6EzeCRNEcUPBNI-fK3nvYQJ4TItudM=.00584b6b-f4a8-486a-b0c4-40d77bca5f2b@github.com>
 <aHDr92oHMRPJubJTAe0dGrRF2ghU9NV51pYvb-Zoyww=.005fcce8-015b-4887-9218-bca276b0d0d9@github.com>
 <wvdY9nzY-oc_mFfvcgu_QG1eMW0R8tiwsDs31SshE80=.6ba027d8-8697-4032-94b6-d2833e2b08e6@github.com>
 <fL_OU_j4Qng34fuvED-PquCVdLfXq28Pb5oDl84RDQs=.2d3a75e4-e090-4d5a-a9be-fae1e638fe5b@github.com>
 <qOMuoVNdwPFRfg1wUGqttP1qdRTuRuWrwIBvJ8CSVOE=.e01ed1f1-71ba-4ea4-a074-966e558769d3@github.com>
Message-ID: <tEP9cgWoEvbcCjiL1jpP04Y60kVOEOwQea9zdf-GshA=.6bc24ad4-dc9f-4abf-b2ae-c577f011a8f0@github.com>

On Thu, 8 Jun 2023 03:36:52 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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

From sspitsyn at openjdk.org  Thu Jun  8 04:34:47 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 8 Jun 2023 04:34:47 GMT
Subject: RFR: 8232839: JDI AfterThreadDeathTest.java failed due to
 "FAILED: Did not get expected IllegalThreadStateException on a
 StepRequest.enable()"
In-Reply-To: <m1pRv9k7_76AZd_GEgPWd3YTrKJuDi_EClmi7s-vNJs=.61e06dcc-7e8f-4683-bebd-3c9305c308e4@github.com>
References: <m1pRv9k7_76AZd_GEgPWd3YTrKJuDi_EClmi7s-vNJs=.61e06dcc-7e8f-4683-bebd-3c9305c308e4@github.com>
Message-ID: <k8MjyJRSdE3nQMZ2OZ_iDjoqi9ipuenDn3UK36u5MCA=.13e71a88-47d5-455e-a7fe-c547eaa2214e@github.com>

On Wed, 7 Jun 2023 23:17:18 GMT, Chris Plummer <cjplummer at openjdk.org> 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

From sspitsyn at openjdk.org  Thu Jun  8 04:46:50 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 8 Jun 2023 04:46:50 GMT
Subject: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier
 should return STATE_WAITING [v4]
In-Reply-To: <tEP9cgWoEvbcCjiL1jpP04Y60kVOEOwQea9zdf-GshA=.6bc24ad4-dc9f-4abf-b2ae-c577f011a8f0@github.com>
References: <2yWxf_TT2Dw2LLUa9fs8GZM-EfYIAOD-mTv1GLmg6o4=.705caff7-40a4-4dcb-862f-cebac0be68db@github.com>
 <Ytu2WnAYrR-fm_wwnxbfuJv8Dvj2GQDL1eGoJZ2SrVU=.95270690-1da0-4cd0-a97a-c65ed6ba3983@github.com>
 <8pd-OWsWDM6RK-_X479uitxD-NNERoHXggUi4F7iemM=.229a79e8-5140-456b-80ba-2916e7dd95d9@github.com>
 <ZefSu_UYkpzXgX5hFJFIvf0e1cv5W2YAfdGWMaZYZuU=.1c53c003-4b84-48ff-85cb-3cd8fa2aced6@github.com>
 <btSx8TZ6nbKRVHw5aUdr4q6nOIC7eCIcv9LSxaY4GVg=.5e932ef8-d00b-4535-a117-42290b1f458f@github.com>
 <_52Zqcx-rftOA6EzeCRNEcUPBNI-fK3nvYQJ4TItudM=.00584b6b-f4a8-486a-b0c4-40d77bca5f2b@github.com>
 <aHDr92oHMRPJubJTAe0dGrRF2ghU9NV51pYvb-Zoyww=.005fcce8-015b-4887-9218-bca276b0d0d9@github.com>
 <wvdY9nzY-oc_mFfvcgu_QG1eMW0R8tiwsDs31SshE80=.6ba027d8-8697-4032-94b6-d2833e2b08e6@github.com>
 <fL_OU_j4Qng34fuvED-PquCVdLfXq28Pb5oDl84RDQs=.2d3a75e4-e090-4d5a-a9be-fae1e638fe5b@github.com>
 <qOMuoVNdwPFRfg1wUGqttP1qdRTuRuWrwIBvJ8CSVOE=.e01ed1f1-71ba-4ea4-a074-966e558769d3@github.com>
 <tEP9cgWoEvbcCjiL1jpP04Y60kVOEOwQea9
 zdf-GshA=.6bc24ad4-dc9f-4abf-b2ae-c577f011a8f0@github.com>
Message-ID: <MPe-eaK1YlQpa5TwtnJ2WoELS3K7dPiUlHPLR7wWNZQ=.2ff31f5d-ebd7-4dc4-889e-e0761925012a@github.com>

On Thu, 8 Jun 2023 04:29:47 GMT, David Holmes <dholmes at openjdk.org> 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

From alanb at openjdk.org  Thu Jun  8 06:27:49 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 8 Jun 2023 06:27:49 GMT
Subject: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier
 should return STATE_WAITING [v4]
In-Reply-To: <MPe-eaK1YlQpa5TwtnJ2WoELS3K7dPiUlHPLR7wWNZQ=.2ff31f5d-ebd7-4dc4-889e-e0761925012a@github.com>
References: <2yWxf_TT2Dw2LLUa9fs8GZM-EfYIAOD-mTv1GLmg6o4=.705caff7-40a4-4dcb-862f-cebac0be68db@github.com>
 <Ytu2WnAYrR-fm_wwnxbfuJv8Dvj2GQDL1eGoJZ2SrVU=.95270690-1da0-4cd0-a97a-c65ed6ba3983@github.com>
 <8pd-OWsWDM6RK-_X479uitxD-NNERoHXggUi4F7iemM=.229a79e8-5140-456b-80ba-2916e7dd95d9@github.com>
 <ZefSu_UYkpzXgX5hFJFIvf0e1cv5W2YAfdGWMaZYZuU=.1c53c003-4b84-48ff-85cb-3cd8fa2aced6@github.com>
 <btSx8TZ6nbKRVHw5aUdr4q6nOIC7eCIcv9LSxaY4GVg=.5e932ef8-d00b-4535-a117-42290b1f458f@github.com>
 <_52Zqcx-rftOA6EzeCRNEcUPBNI-fK3nvYQJ4TItudM=.00584b6b-f4a8-486a-b0c4-40d77bca5f2b@github.com>
 <aHDr92oHMRPJubJTAe0dGrRF2ghU9NV51pYvb-Zoyww=.005fcce8-015b-4887-9218-bca276b0d0d9@github.com>
 <wvdY9nzY-oc_mFfvcgu_QG1eMW0R8tiwsDs31SshE80=.6ba027d8-8697-4032-94b6-d2833e2b08e6@github.com>
 <fL_OU_j4Qng34fuvED-PquCVdLfXq28Pb5oDl84RDQs=.2d3a75e4-e090-4d5a-a9be-fae1e638fe5b@github.com>
 <qOMuoVNdwPFRfg1wUGqttP1qdRTuRuWrwIBvJ8CSVOE=.e01ed1f1-71ba-4ea4-a074-966e558769d3@github.com>
 <tEP9cgWoEvbcCjiL1jpP04Y60kVOEOwQea9
 zdf-GshA=.6bc24ad4-dc9f-4abf-b2ae-c577f011a8f0@github.com>
 <MPe-eaK1YlQpa5TwtnJ2WoELS3K7dPiUlHPLR7wWNZQ=.2ff31f5d-ebd7-4dc4-889e-e0761925012a@github.com>
Message-ID: <oWV7olq4__pTGDtiskPNhezFlJjcPmTpxoX2VzOvjo4=.37aca33f-7d53-4212-938b-033eb874ecbe@github.com>

On Thu, 8 Jun 2023 04:41:10 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> 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.

The mental model  is that the carrier is blocked so this is what an observer using the APIs should see. My recollection is that JVMTI_THREAD_STATE_WAITING was okay because there is a wriggle room in the JVM TI spec, it only uses Object.wait as an example. There may be a few rough edges to smooth down in this area. It's okay to take time with this PR and expand the tests to cover more cases and get more confident that there aren't more issues.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14366#discussion_r1222511997

From jwaters at openjdk.org  Thu Jun  8 07:45:53 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 8 Jun 2023 07:45:53 GMT
Subject: RFR: 8305341: Alignment should be enforced by alignas instead of
 compiler specific attributes [v4]
In-Reply-To: <dlMKfkRoYlEOlABs5J-mW-Mbr-M3Kv455fgrnmj0A1w=.954ab66c-6dfb-44e7-9546-455e38e35f4a@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
 <dlMKfkRoYlEOlABs5J-mW-Mbr-M3Kv455fgrnmj0A1w=.954ab66c-6dfb-44e7-9546-455e38e35f4a@github.com>
Message-ID: <6x5TNtFwNDmFEx3WL4_uB-PLyFGgi9T0s4rMKEC-iVI=.120ae51e-3d33-46cd-97ce-6cb6b7bde452@github.com>

On Wed, 12 Apr 2023 07:12:10 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements
>
> Julian Waters has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Restore visCPP
>  - Restore gcc attribute
>  - Revert gcc
>  - Revert

Anyone?

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

PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1582065715

From aph at openjdk.org  Thu Jun  8 08:25:35 2023
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 8 Jun 2023 08:25:35 GMT
Subject: RFR: JDK-8307314: Implementation: Generational Shenandoah
 (Experimental) [v17]
In-Reply-To: <HJIK3lzM529ykBDReoHTqNgNSXEwhAE2JfadpV8iSEk=.a4f1a8e2-8290-4102-a236-9a48e8b254f9@github.com>
References: <QIBdWpBu7uNDXEv8I4qYAcF5fQK8xsebniV6DfU6hl4=.2461c43f-c20c-497a-88e8-dd0f1222303c@github.com>
 <AQ7JahiqfbEGMyeqZPwxx_4ORLBDGrC1Mi0oxQhmlgk=.d37920fe-44cb-4975-8df3-6eb87598f6a1@github.com>
 <HJIK3lzM529ykBDReoHTqNgNSXEwhAE2JfadpV8iSEk=.a4f1a8e2-8290-4102-a236-9a48e8b254f9@github.com>
Message-ID: <zJXDJ3e-BWQbJyumE6_h1MSVEzbnGoNWuNlLOVp01tM=.cfcbc9dc-9457-4f13-be36-d7208424670f@github.com>

On Wed, 7 Jun 2023 21:03:47 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> 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.

Thank you for this. It's the right decision. In hindsight, there never was a highly-likely prospect of getting such a substantial and interwoven patch successfully reviewed in such a short time, even with the most skilful and experienced team.

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

PR Comment: https://git.openjdk.org/jdk/pull/14185#issuecomment-1582124942

From yzheng at openjdk.org  Thu Jun  8 17:40:03 2023
From: yzheng at openjdk.org (Yudi Zheng)
Date: Thu, 8 Jun 2023 17:40:03 GMT
Subject: RFR: 8309671: Avoid using jvmci.Compiler property to determine if
 Graal is enabled
Message-ID: <IawBz7ECRbEFc1GCsQzaP0-LR7HwlplLrLkuZOnn-fk=.ac148e99-c5c4-4571-abaa-6025458e63ce@github.com>

HeapMonitor checks if System.getProperty("jvmci.Compiler") is graal and will not enforce checking line number derived from uncommon trap debug info. However, Graal does not set this property explicitly.

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

Commit messages:
 - Avoid using jvmci.Compiler property to determine if Graal is enabled.

Changes: https://git.openjdk.org/jdk/pull/14381/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14381&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309671
  Stats: 3 lines in 2 files changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14381.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14381/head:pull/14381

PR: https://git.openjdk.org/jdk/pull/14381

From dnsimon at openjdk.org  Thu Jun  8 17:40:04 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 8 Jun 2023 17:40:04 GMT
Subject: RFR: 8309671: Avoid using jvmci.Compiler property to determine if
 Graal is enabled
In-Reply-To: <IawBz7ECRbEFc1GCsQzaP0-LR7HwlplLrLkuZOnn-fk=.ac148e99-c5c4-4571-abaa-6025458e63ce@github.com>
References: <IawBz7ECRbEFc1GCsQzaP0-LR7HwlplLrLkuZOnn-fk=.ac148e99-c5c4-4571-abaa-6025458e63ce@github.com>
Message-ID: <3Sa8G0j18gcxBvSRPq_Uoa1AzqBvST1aW4KNdH8V5oI=.79ebc9bf-8ee7-4c95-8d51-540014d26de1@github.com>

On Thu, 8 Jun 2023 17:14:39 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

> HeapMonitor checks if System.getProperty("jvmci.Compiler") is graal and will not enforce checking line number derived from uncommon trap debug info. However, Graal does not set this property explicitly.

test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitor.java line 257:

> 255: 
> 256:       checkLines = !(enableJVMCI.getValue().equals("true")
> 257:           && useJVMCICompiler.getValue().equals("true"));

Is it possible to use `jdk.test.whitebox.code.Compiler.isGraalEnabled()` here instead?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14381#discussion_r1223342262

From amenkov at openjdk.org  Thu Jun  8 18:21:44 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 8 Jun 2023 18:21:44 GMT
Subject: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier
 should return STATE_WAITING [v6]
In-Reply-To: <EsD9Wc5sp6cVd6EgqH6qI0umSVAQRbVw1ls2D5bhMhU=.5ff76185-0ef4-4a52-8aab-340fee00b285@github.com>
References: <2yWxf_TT2Dw2LLUa9fs8GZM-EfYIAOD-mTv1GLmg6o4=.705caff7-40a4-4dcb-862f-cebac0be68db@github.com>
 <EsD9Wc5sp6cVd6EgqH6qI0umSVAQRbVw1ls2D5bhMhU=.5ff76185-0ef4-4a52-8aab-340fee00b285@github.com>
Message-ID: <HtlsNXv-aLXs7vfM4ZDxIEw4y39pEOKa33RKMiOiRzw=.9ee44b00-1e04-422e-a32d-384c9f1dd81b@github.com>

On Thu, 8 Jun 2023 01:42:10 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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: corrected the function get_thread_state for safety

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14366#pullrequestreview-1470533353

From yzheng at openjdk.org  Thu Jun  8 18:32:55 2023
From: yzheng at openjdk.org (Yudi Zheng)
Date: Thu, 8 Jun 2023 18:32:55 GMT
Subject: RFR: 8309671: Avoid using jvmci.Compiler property to determine if
 Graal is enabled
In-Reply-To: <3Sa8G0j18gcxBvSRPq_Uoa1AzqBvST1aW4KNdH8V5oI=.79ebc9bf-8ee7-4c95-8d51-540014d26de1@github.com>
References: <IawBz7ECRbEFc1GCsQzaP0-LR7HwlplLrLkuZOnn-fk=.ac148e99-c5c4-4571-abaa-6025458e63ce@github.com>
 <3Sa8G0j18gcxBvSRPq_Uoa1AzqBvST1aW4KNdH8V5oI=.79ebc9bf-8ee7-4c95-8d51-540014d26de1@github.com>
Message-ID: <K7_CSWRi7U6j58U6wuk4Rfrf6HBEWHVtO99lFuKxqFI=.9907bbec-8576-45a6-a0c6-8b4d7c04b602@github.com>

On Thu, 8 Jun 2023 17:19:46 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> HeapMonitor checks if System.getProperty("jvmci.Compiler") is graal and will not enforce checking line number derived from uncommon trap debug info. However, Graal does not set this property explicitly.
>
> test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitor.java line 257:
> 
>> 255: 
>> 256:       checkLines = !(enableJVMCI.getValue().equals("true")
>> 257:           && useJVMCICompiler.getValue().equals("true"));
> 
> Is it possible to use `jdk.test.whitebox.code.Compiler.isGraalEnabled()` here instead?

To use whitebox I will have to update the config of every test here, which I think is too verbose:

diff --git a/test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatIntervalTest.java b/test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatIntervalTest.java
index e08454a4857..f086f744965 100644
--- a/test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatIntervalTest.java
+++ b/test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatIntervalTest.java
@@ -27,11 +27,15 @@ package MyPackage;
 /**
  * @test
  * @summary Verifies the JVMTI Heap Monitor sampling interval average.
- * @build Frame HeapMonitor
+ * @library /test/lib
+ * @build Frame HeapMonitor jdk.test.whitebox.WhiteBox
  * @compile HeapMonitorStatIntervalTest.java
  * @requires vm.jvmti
  * @requires vm.compMode != "Xcomp"
- * @run main/othervm/native -agentlib:HeapMonitorTest MyPackage.HeapMonitorStatIntervalTest
+ * @run driver jdk.test.lib.helpers.ClassFileInstaller jdk.test.whitebox.WhiteBox
+ * @run main/othervm/native -agentlib:HeapMonitorTest -Xbootclasspath/a:.
+ *                   -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI
+ *                   MyPackage.HeapMonitorStatIntervalTest
  */

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14381#discussion_r1223411115

From dnsimon at openjdk.org  Thu Jun  8 19:08:53 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 8 Jun 2023 19:08:53 GMT
Subject: RFR: 8306028: separate ThreadStart/ThreadEnd events posting code
 in JVMTI VTMS transitions [v8]
In-Reply-To: <vAIknmNqUhDBDAIuiyxAcX-f85YBfWLy3NgEkQvFUlI=.d5b57f83-b287-4864-91b6-4591ab490174@github.com>
References: <hDtNgWU6JkRUGc9l8SftQjB-oS8mfr8JGzbvyNUpDg0=.d8a94eb6-59d6-4ba4-b3df-f9a133502a2a@github.com>
 <vAIknmNqUhDBDAIuiyxAcX-f85YBfWLy3NgEkQvFUlI=.d5b57f83-b287-4864-91b6-4591ab490174@github.com>
Message-ID: <9RJb8PvlZxLYs2zsDb-lDqoILDkiFwPx54vq3NpIdQQ=.c158dc31-68b0-49bd-8ac4-1ff1069be454@github.com>

On Tue, 2 May 2023 02:01:44 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This refactoring to separate ThreadStart/ThreadEnd events posting code in the JVMTI VTMS transitions is needed for future work on JVMTI scalability and performance improvements. It is to easier put this code on slow path.
>> 
>> Testing: mach5 tiers 1-6 were successful.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright comments

src/hotspot/share/runtime/sharedRuntime.cpp line 641:

> 639: JRT_ENTRY(void, SharedRuntime::notify_jvmti_vthread_start(oopDesc* vt, jboolean hide, JavaThread* current))
> 640:   assert(hide == JNI_FALSE, "must be VTMS transition finish");
> 641:   jobject vthread = JNIHandles::make_local(const_cast<oopDesc*>(vt));

Since the current thread is in the `current` arg, it could be used here when creating the local handle.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13484#discussion_r1223444559

From dnsimon at openjdk.org  Thu Jun  8 19:12:40 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 8 Jun 2023 19:12:40 GMT
Subject: RFR: 8309671: Avoid using jvmci.Compiler property to determine if
 Graal is enabled
In-Reply-To: <IawBz7ECRbEFc1GCsQzaP0-LR7HwlplLrLkuZOnn-fk=.ac148e99-c5c4-4571-abaa-6025458e63ce@github.com>
References: <IawBz7ECRbEFc1GCsQzaP0-LR7HwlplLrLkuZOnn-fk=.ac148e99-c5c4-4571-abaa-6025458e63ce@github.com>
Message-ID: <8FdRus4tjvM7FAZ9HAOTbQpbgJKfWw8lyJWAZmbnRFU=.8a73dd98-f8ac-421c-bdb6-5fe9733577c3@github.com>

On Thu, 8 Jun 2023 17:14:39 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

> HeapMonitor checks if System.getProperty("jvmci.Compiler") is graal and will not enforce checking line number derived from uncommon trap debug info. However, Graal does not set this property explicitly.

Marked as reviewed by dnsimon (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/14381#pullrequestreview-1470601144

From dnsimon at openjdk.org  Thu Jun  8 19:12:42 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 8 Jun 2023 19:12:42 GMT
Subject: RFR: 8309671: Avoid using jvmci.Compiler property to determine if
 Graal is enabled
In-Reply-To: <K7_CSWRi7U6j58U6wuk4Rfrf6HBEWHVtO99lFuKxqFI=.9907bbec-8576-45a6-a0c6-8b4d7c04b602@github.com>
References: <IawBz7ECRbEFc1GCsQzaP0-LR7HwlplLrLkuZOnn-fk=.ac148e99-c5c4-4571-abaa-6025458e63ce@github.com>
 <3Sa8G0j18gcxBvSRPq_Uoa1AzqBvST1aW4KNdH8V5oI=.79ebc9bf-8ee7-4c95-8d51-540014d26de1@github.com>
 <K7_CSWRi7U6j58U6wuk4Rfrf6HBEWHVtO99lFuKxqFI=.9907bbec-8576-45a6-a0c6-8b4d7c04b602@github.com>
Message-ID: <V8RmW2QxFqvWsYYvcUrnjUtGkCbismUN4n_Rcu9Qgv4=.5decf485-7413-4ca2-b362-cccb9e8c197e@github.com>

On Thu, 8 Jun 2023 18:29:50 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitor.java line 257:
>> 
>>> 255: 
>>> 256:       checkLines = !(enableJVMCI.getValue().equals("true")
>>> 257:           && useJVMCICompiler.getValue().equals("true"));
>> 
>> Is it possible to use `jdk.test.whitebox.code.Compiler.isGraalEnabled()` here instead?
>
> To use whitebox I will have to update the config of every test here, which I think is too verbose:
> 
> diff --git a/test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatIntervalTest.java b/test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatIntervalTest.java
> index e08454a4857..f086f744965 100644
> --- a/test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatIntervalTest.java
> +++ b/test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatIntervalTest.java
> @@ -27,11 +27,15 @@ package MyPackage;
>  /**
>   * @test
>   * @summary Verifies the JVMTI Heap Monitor sampling interval average.
> - * @build Frame HeapMonitor
> + * @library /test/lib
> + * @build Frame HeapMonitor jdk.test.whitebox.WhiteBox
>   * @compile HeapMonitorStatIntervalTest.java
>   * @requires vm.jvmti
>   * @requires vm.compMode != "Xcomp"
> - * @run main/othervm/native -agentlib:HeapMonitorTest MyPackage.HeapMonitorStatIntervalTest
> + * @run driver jdk.test.lib.helpers.ClassFileInstaller jdk.test.whitebox.WhiteBox
> + * @run main/othervm/native -agentlib:HeapMonitorTest -Xbootclasspath/a:.
> + *                   -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI
> + *                   MyPackage.HeapMonitorStatIntervalTest
>   */

Ok.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14381#discussion_r1223447124

From phh at openjdk.org  Thu Jun  8 19:20:40 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Thu, 8 Jun 2023 19:20:40 GMT
Subject: RFR: 8309271: A way to align already compiled methods with
 compiler directives
In-Reply-To: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
References: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
Message-ID: <Qmli4eMUo8KrSnX4GzIYAGTm-U6yxnyaKj8qCoq9tS4=.2a098703-676e-435c-8145-8ebd608c2d3a@github.com>

On Wed, 24 May 2023 00:38:27 GMT, Dmitry Chuyko <dchuyko at openjdk.org> wrote:

> Compiler Control (https://openjdk.org/jeps/165) provides method-context dependent control of the JVM compilers (C1 and C2). The active directive stack is built from the directive files passed with the `-XX:CompilerDirectivesFile` diagnostic command-line option and the Compiler.add_directives diagnostic command. It is also possible to clear all directives or remove the top from the stack.
> 
> A matching directive will be applied at method compilation time when such compilation is started. If directives are added or changed, but compilation does not start, then the state of compiled methods doesn't correspond to the rules. This is not an error, and it happens in long running applications when directives are added or removed after compilation of methods that could be matched. For example, the user decides that C2 compilation needs to be disabled for some method due to a compiler bug, issues such a directive but this does not affect the application behavior. In such case, the target application needs to be restarted, and such an operation can have high costs and risks. Another goal is testing/debugging compilers.
> 
> It would be convenient to optionally reconcile at least existing matching nmethods to the current stack of compiler directives. Methods in general are often inlined, and this information is hard to track down.
> 
> Natural way to eliminate the discrepancy between the result of compilation and the broken rule is to discard the compilation result, i.e. deoptimization. Obviously there is a performance penalty, so it should be applied with care. Hot code will most likely be recompiled soon, as nothing happens to its hotness.
> 
> A new flag '`-d`' has beed introduced for some directives related to compile commands: `Compiler.add_directives`, `Compiler.remove_directives`, `Compiler.clear_directives`. The default behavior has not changed (no flag). If the new flag is present, the command scans already compiled methods and marks for deoptimization those methods that have any active non-default matching compiler directives. There is currently no distinction which directives are found. In particular, this means that if there are rules for inlining into some method, it will be deoptimized. On the other hand, if there are rules for a method and it was inlined, top-level methods won't be deoptimized, but this can be achieved by having rules for them.
> 
> In addition, a new diagnistic command `Compiler.replace_directives`, has been added for convenience. It's like a combinatio...

"refresh" (-r) would be better than "deoptimize" (-d). The latter implies a specific implementation, the former is generic.

If the method is to be recompiled, perhaps rather than deopt and wait, add it to the compile queue immediately and deopt the old version when the new compilation is complete, similar to what happens when the c1 version of the method is replaced by the c2 version.

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

PR Comment: https://git.openjdk.org/jdk/pull/14111#issuecomment-1583199824

From kevinw at openjdk.org  Thu Jun  8 19:36:43 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 8 Jun 2023 19:36:43 GMT
Subject: RFR: 8232839: JDI AfterThreadDeathTest.java failed due to
 "FAILED: Did not get expected IllegalThreadStateException on a
 StepRequest.enable()"
In-Reply-To: <m1pRv9k7_76AZd_GEgPWd3YTrKJuDi_EClmi7s-vNJs=.61e06dcc-7e8f-4683-bebd-3c9305c308e4@github.com>
References: <m1pRv9k7_76AZd_GEgPWd3YTrKJuDi_EClmi7s-vNJs=.61e06dcc-7e8f-4683-bebd-3c9305c308e4@github.com>
Message-ID: <zNA3nMh2lSwLRUgXRRsnSHhYFHECg4Z7iFcD7Jz0mwE=.2320dc80-f28e-47bd-b5c4-efa65739ecf3@github.com>

On Wed, 7 Jun 2023 23:17:18 GMT, Chris Plummer <cjplummer at openjdk.org> 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.

I think it makes sense!

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

Marked as reviewed by kevinw (Committer).

PR Review: https://git.openjdk.org/jdk/pull/14372#pullrequestreview-1470630717

From matsaave at openjdk.org  Thu Jun  8 22:01:11 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 8 Jun 2023 22:01:11 GMT
Subject: RFR: 8309673: Refactor ref_at methods in Serviceability ConstantPool
Message-ID: <hRsZfM8S0Lm5YNnE-rONBi_ikCFCfsEAK0WLl3j-9co=.59c8f460-58ee-4d97-bdca-24d539de95ca@github.com>

The accessor methods in constantpool.cpp were previously cleaned up to allow for different types of indices to be used, distinguishing them by the bytecode. This patch adds the same changes to the hotspot serviceability code. Verified with tier 1-5 tests.

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

Commit messages:
 - 8309673: Refactor ref_at methods in Serviceability ConstantPool

Changes: https://git.openjdk.org/jdk/pull/14385/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14385&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309673
  Stats: 95 lines in 4 files changed: 32 ins; 25 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/14385.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14385/head:pull/14385

PR: https://git.openjdk.org/jdk/pull/14385

From sspitsyn at openjdk.org  Fri Jun  9 05:15:56 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 9 Jun 2023 05:15:56 GMT
Subject: RFR: 8306028: separate ThreadStart/ThreadEnd events posting code
 in JVMTI VTMS transitions [v8]
In-Reply-To: <9RJb8PvlZxLYs2zsDb-lDqoILDkiFwPx54vq3NpIdQQ=.c158dc31-68b0-49bd-8ac4-1ff1069be454@github.com>
References: <hDtNgWU6JkRUGc9l8SftQjB-oS8mfr8JGzbvyNUpDg0=.d8a94eb6-59d6-4ba4-b3df-f9a133502a2a@github.com>
 <vAIknmNqUhDBDAIuiyxAcX-f85YBfWLy3NgEkQvFUlI=.d5b57f83-b287-4864-91b6-4591ab490174@github.com>
 <9RJb8PvlZxLYs2zsDb-lDqoILDkiFwPx54vq3NpIdQQ=.c158dc31-68b0-49bd-8ac4-1ff1069be454@github.com>
Message-ID: <JBTJ0z3KXTI3nuPkNYgWTKT_ERsvElRISnPehgH87o4=.14b2c10c-7c94-4aed-bb18-f0fcffe5ffe6@github.com>

On Thu, 8 Jun 2023 19:05:54 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update copyright comments
>
> src/hotspot/share/runtime/sharedRuntime.cpp line 641:
> 
>> 639: JRT_ENTRY(void, SharedRuntime::notify_jvmti_vthread_start(oopDesc* vt, jboolean hide, JavaThread* current))
>> 640:   assert(hide == JNI_FALSE, "must be VTMS transition finish");
>> 641:   jobject vthread = JNIHandles::make_local(const_cast<oopDesc*>(vt));
> 
> Since the current thread is in the `current` arg, it could be used here when creating the local handle.

That's right. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13484#discussion_r1223851214

From sspitsyn at openjdk.org  Fri Jun  9 05:29:40 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 9 Jun 2023 05:29:40 GMT
Subject: RFR: 8309671: Avoid using jvmci.Compiler property to determine if
 Graal is enabled
In-Reply-To: <IawBz7ECRbEFc1GCsQzaP0-LR7HwlplLrLkuZOnn-fk=.ac148e99-c5c4-4571-abaa-6025458e63ce@github.com>
References: <IawBz7ECRbEFc1GCsQzaP0-LR7HwlplLrLkuZOnn-fk=.ac148e99-c5c4-4571-abaa-6025458e63ce@github.com>
Message-ID: <vmLY_SLrhMau31-t5ijS-y2q0DcNy-sy7CaF5HuoBq0=.af5cdf71-1126-4958-a918-86f5afd0a6bc@github.com>

On Thu, 8 Jun 2023 17:14:39 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

> HeapMonitor checks if System.getProperty("jvmci.Compiler") is graal and will not enforce checking line number derived from uncommon trap debug info. However, Graal does not set this property explicitly.

Looks good.
Is JVMCI used by the Graal compiler only?
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14381#pullrequestreview-1471250105

From sspitsyn at openjdk.org  Fri Jun  9 06:17:49 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 9 Jun 2023 06:17:49 GMT
Subject: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier
 should return STATE_WAITING [v4]
In-Reply-To: <oWV7olq4__pTGDtiskPNhezFlJjcPmTpxoX2VzOvjo4=.37aca33f-7d53-4212-938b-033eb874ecbe@github.com>
References: <2yWxf_TT2Dw2LLUa9fs8GZM-EfYIAOD-mTv1GLmg6o4=.705caff7-40a4-4dcb-862f-cebac0be68db@github.com>
 <Ytu2WnAYrR-fm_wwnxbfuJv8Dvj2GQDL1eGoJZ2SrVU=.95270690-1da0-4cd0-a97a-c65ed6ba3983@github.com>
 <8pd-OWsWDM6RK-_X479uitxD-NNERoHXggUi4F7iemM=.229a79e8-5140-456b-80ba-2916e7dd95d9@github.com>
 <ZefSu_UYkpzXgX5hFJFIvf0e1cv5W2YAfdGWMaZYZuU=.1c53c003-4b84-48ff-85cb-3cd8fa2aced6@github.com>
 <btSx8TZ6nbKRVHw5aUdr4q6nOIC7eCIcv9LSxaY4GVg=.5e932ef8-d00b-4535-a117-42290b1f458f@github.com>
 <_52Zqcx-rftOA6EzeCRNEcUPBNI-fK3nvYQJ4TItudM=.00584b6b-f4a8-486a-b0c4-40d77bca5f2b@github.com>
 <aHDr92oHMRPJubJTAe0dGrRF2ghU9NV51pYvb-Zoyww=.005fcce8-015b-4887-9218-bca276b0d0d9@github.com>
 <wvdY9nzY-oc_mFfvcgu_QG1eMW0R8tiwsDs31SshE80=.6ba027d8-8697-4032-94b6-d2833e2b08e6@github.com>
 <fL_OU_j4Qng34fuvED-PquCVdLfXq28Pb5oDl84RDQs=.2d3a75e4-e090-4d5a-a9be-fae1e638fe5b@github.com>
 <qOMuoVNdwPFRfg1wUGqttP1qdRTuRuWrwIBvJ8CSVOE=.e01ed1f1-71ba-4ea4-a074-966e558769d3@github.com>
 <tEP9cgWoEvbcCjiL1jpP04Y60kVOEOwQea9
 zdf-GshA=.6bc24ad4-dc9f-4abf-b2ae-c577f011a8f0@github.com>
 <MPe-eaK1YlQpa5TwtnJ2WoELS3K7dPiUlHPLR7wWNZQ=.2ff31f5d-ebd7-4dc4-889e-e0761925012a@github.com>
 <oWV7olq4__pTGDtiskPNhezFlJjcPmTpxoX2VzOvjo4=.37aca33f-7d53-4212-938b-033eb874ecbe@github.com>
Message-ID: <rzpLstHkxxG4dGywmROLNNPZRi0DhIhCqXU0YJZtlRE=.8aa0be24-a87f-461d-aec3-064ecb8a19b8@github.com>

On Thu, 8 Jun 2023 06:25:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> 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.
>
> The mental model  is that the carrier is blocked so this is what an observer using the APIs should see. My recollection is that JVMTI_THREAD_STATE_WAITING was okay because there is a wriggle room in the JVM TI spec, it only uses Object.wait as an example. There may be a few rough edges to smooth down in this area. It's okay to take time with this PR and expand the tests to cover more cases and get more confident that there aren't more issues.

We agreed with Alex to file a test RFE to improve test coverage in this area.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14366#discussion_r1223883294

From sspitsyn at openjdk.org  Fri Jun  9 06:17:51 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 9 Jun 2023 06:17:51 GMT
Subject: Integrated: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on
 carrier should return STATE_WAITING
In-Reply-To: <2yWxf_TT2Dw2LLUa9fs8GZM-EfYIAOD-mTv1GLmg6o4=.705caff7-40a4-4dcb-862f-cebac0be68db@github.com>
References: <2yWxf_TT2Dw2LLUa9fs8GZM-EfYIAOD-mTv1GLmg6o4=.705caff7-40a4-4dcb-862f-cebac0be68db@github.com>
Message-ID: <efhTKkTB8cF3ya6IExrErEXuYiM08t7DbEVgp37YiMA=.e8cf9d99-3764-44be-a22f-4295ed415061@github.com>

On Wed, 7 Jun 2023 18:42:34 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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

This pull request has now been integrated.

Changeset: f91e9ba7
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f91e9ba757f04983655c23542e06973805465249
Stats:     96 lines in 4 files changed: 76 ins; 0 del; 20 mod

8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING

Reviewed-by: cjplummer, amenkov

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

PR: https://git.openjdk.org/jdk/pull/14366

From sspitsyn at openjdk.org  Fri Jun  9 06:26:50 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 9 Jun 2023 06:26:50 GMT
Subject: RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier
 should return STATE_WAITING [v6]
In-Reply-To: <EsD9Wc5sp6cVd6EgqH6qI0umSVAQRbVw1ls2D5bhMhU=.5ff76185-0ef4-4a52-8aab-340fee00b285@github.com>
References: <2yWxf_TT2Dw2LLUa9fs8GZM-EfYIAOD-mTv1GLmg6o4=.705caff7-40a4-4dcb-862f-cebac0be68db@github.com>
 <EsD9Wc5sp6cVd6EgqH6qI0umSVAQRbVw1ls2D5bhMhU=.5ff76185-0ef4-4a52-8aab-340fee00b285@github.com>
Message-ID: <xa6SwQ_RuYZr_vsQS1-_QLJ3uUvg35HVoiegGuqhHBg=.6f30e76d-53b3-482e-8708-69620bec69f6@github.com>

On Thu, 8 Jun 2023 01:42:10 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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: corrected the function get_thread_state for safety

Chris and Alex, thank you for review!

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

PR Comment: https://git.openjdk.org/jdk/pull/14366#issuecomment-1584039912

From dnsimon at openjdk.org  Fri Jun  9 12:17:42 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 9 Jun 2023 12:17:42 GMT
Subject: RFR: 8309671: Avoid using jvmci.Compiler property to determine if
 Graal is enabled
In-Reply-To: <vmLY_SLrhMau31-t5ijS-y2q0DcNy-sy7CaF5HuoBq0=.af5cdf71-1126-4958-a918-86f5afd0a6bc@github.com>
References: <IawBz7ECRbEFc1GCsQzaP0-LR7HwlplLrLkuZOnn-fk=.ac148e99-c5c4-4571-abaa-6025458e63ce@github.com>
 <vmLY_SLrhMau31-t5ijS-y2q0DcNy-sy7CaF5HuoBq0=.af5cdf71-1126-4958-a918-86f5afd0a6bc@github.com>
Message-ID: <29D590lYaxvw5XS9uU-De3N2NJ3thhNWoWU7eQkhpfc=.80aa7b3c-7ab2-41a9-940f-8db0caefaaee@github.com>

On Fri, 9 Jun 2023 05:26:59 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Is JVMCI used by the Graal compiler only?

So far this is true and will probably remain true for the foreseeable future. However, the Right Thing to do long term is to add a `jdk.test.whitebox.code.Compiler.uncommonTrapsHavePreciseBCIs()` method.

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

PR Comment: https://git.openjdk.org/jdk/pull/14381#issuecomment-1584480496

From mbaesken at openjdk.org  Fri Jun  9 13:45:58 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 9 Jun 2023 13:45:58 GMT
Subject: RFR: JDK-8309549:
 com/sun/tools/attach/warnings/DynamicLoadWarningTest.java fails on AIX
Message-ID: <f2Em33V-PEu68TZ9jU2b0oypu9Q5aGcw1ma-iwS8SLk=.22c2b252-38d7-4070-9d78-89d231bec6f7@github.com>

On AIX ,  new jtreg test  com/sun/tools/attach/warnings/DynamicLoadWarningTest.java always failed  with the output :

----------System.err:(294/28579)----------
STARTED DynamicLoadWarningTest::testLoadJavaAgent 'testLoadJavaAgent()'
SUCCESSFUL DynamicLoadWarningTest::testLoadJavaAgent 'testLoadJavaAgent()'
STARTED DynamicLoadWarningTest::testLoadOneJvmtiAgent '[1] DynamicLoadWarningTest$$Lambda/0x000000040020bd88 at 600d90bb'
org.opentest4j.AssertionFailedError: expected: <1> but was: <2>
at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145)
at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:528)
at DynamicLoadWarningTest$AppRunner.stderrShouldContain(DynamicLoadWarningTest.java:298)
at DynamicLoadWarningTest.testLoadOneJvmtiAgent(DynamicLoadWarningTest.java:125)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
at java.base/java.lang.reflect.Method.invoke(Method.java:580)

Reason seems to be the different behavior of dlopen on AIX compared to e.g. Linux 
This is what I find in the manpage of AIX 7.2 or 7.3 :
https://www.ibm.com/docs/en/aix/7.2?topic=d-dlopen-subroutine
https://www.ibm.com/docs/en/aix/7.3?topic=d-dlopen-subroutine
'If the module is already loaded, it is not loaded again, but a new, unique value will be returned by the dlopen subroutine.'

Sounds different to what Linux documents in the manpage:
https://man7.org/linux/man-pages/man3/dlopen.3.html
'If the same shared object is opened again with dlopen(), the same object handle is returned.'

We skip this special subtest on AIX .

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

Commit messages:
 - JDK-8309549

Changes: https://git.openjdk.org/jdk/pull/14393/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14393&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309549
  Stats: 7 lines in 1 file changed: 3 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14393.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14393/head:pull/14393

PR: https://git.openjdk.org/jdk/pull/14393

From alanb at openjdk.org  Fri Jun  9 13:58:42 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 Jun 2023 13:58:42 GMT
Subject: RFR: JDK-8309549:
 com/sun/tools/attach/warnings/DynamicLoadWarningTest.java fails on AIX
In-Reply-To: <f2Em33V-PEu68TZ9jU2b0oypu9Q5aGcw1ma-iwS8SLk=.22c2b252-38d7-4070-9d78-89d231bec6f7@github.com>
References: <f2Em33V-PEu68TZ9jU2b0oypu9Q5aGcw1ma-iwS8SLk=.22c2b252-38d7-4070-9d78-89d231bec6f7@github.com>
Message-ID: <IMkz43uCX0IVcnnbipyCkc2A0FguK0vhNM3x-8kGz7Q=.48d33158-bcc9-4f90-9466-4cc005f86ebe@github.com>

On Fri, 9 Jun 2023 13:39:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On AIX ,  new jtreg test  com/sun/tools/attach/warnings/DynamicLoadWarningTest.java always failed  with the output :
> 
> ----------System.err:(294/28579)----------
> STARTED DynamicLoadWarningTest::testLoadJavaAgent 'testLoadJavaAgent()'
> SUCCESSFUL DynamicLoadWarningTest::testLoadJavaAgent 'testLoadJavaAgent()'
> STARTED DynamicLoadWarningTest::testLoadOneJvmtiAgent '[1] DynamicLoadWarningTest$$Lambda/0x000000040020bd88 at 600d90bb'
> org.opentest4j.AssertionFailedError: expected: <1> but was: <2>
> at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
> at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
> at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145)
> at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:528)
> at DynamicLoadWarningTest$AppRunner.stderrShouldContain(DynamicLoadWarningTest.java:298)
> at DynamicLoadWarningTest.testLoadOneJvmtiAgent(DynamicLoadWarningTest.java:125)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> 
> Reason seems to be the different behavior of dlopen on AIX compared to e.g. Linux 
> This is what I find in the manpage of AIX 7.2 or 7.3 :
> https://www.ibm.com/docs/en/aix/7.2?topic=d-dlopen-subroutine
> https://www.ibm.com/docs/en/aix/7.3?topic=d-dlopen-subroutine
> 'If the module is already loaded, it is not loaded again, but a new, unique value will be returned by the dlopen subroutine.'
> 
> Sounds different to what Linux documents in the manpage:
> https://man7.org/linux/man-pages/man3/dlopen.3.html
> 'If the same shared object is opened again with dlopen(), the same object handle is returned.'
> 
> We skip this special subtest on AIX .

Thanks for taking this one. The spec doesn't require warnings be de-duplicated when the same agent library is loaded more than once, thus skipping this test is okay where it's too complex to detect that the agent library is already loaded.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14393#pullrequestreview-1472159054

From coleenp at openjdk.org  Fri Jun  9 14:58:42 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 9 Jun 2023 14:58:42 GMT
Subject: RFR: 8309673: Refactor ref_at methods in Serviceability
 ConstantPool
In-Reply-To: <hRsZfM8S0Lm5YNnE-rONBi_ikCFCfsEAK0WLl3j-9co=.59c8f460-58ee-4d97-bdca-24d539de95ca@github.com>
References: <hRsZfM8S0Lm5YNnE-rONBi_ikCFCfsEAK0WLl3j-9co=.59c8f460-58ee-4d97-bdca-24d539de95ca@github.com>
Message-ID: <xj-YcgJatlXR3rvB04VyndSzRw5UgzzzNONwbwKj37A=.9b4822eb-0283-49d6-a478-d42e71dd7836@github.com>

On Thu, 8 Jun 2023 21:42:24 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> The accessor methods in constantpool.cpp were previously cleaned up to allow for different types of indices to be used, distinguishing them by the bytecode. This patch adds the same changes to the hotspot serviceability code. Verified with tier 1-5 tests.

Looks good.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPool.java line 262:

> 260:       case Bytecodes._invokedynamic:
> 261:         int poolIndex = getCache().getIndyEntryAt(index).getConstantPoolIndex();
> 262:         return poolIndex = invokeDynamicNameAndTypeRefIndexAt(poolIndex);

probably don't need another assignment to poolIndex in the return statement.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14385#pullrequestreview-1472334909
PR Review Comment: https://git.openjdk.org/jdk/pull/14385#discussion_r1224416163

From fparain at openjdk.org  Fri Jun  9 16:55:45 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 9 Jun 2023 16:55:45 GMT
Subject: RFR: 8309673: Refactor ref_at methods in Serviceability
 ConstantPool
In-Reply-To: <hRsZfM8S0Lm5YNnE-rONBi_ikCFCfsEAK0WLl3j-9co=.59c8f460-58ee-4d97-bdca-24d539de95ca@github.com>
References: <hRsZfM8S0Lm5YNnE-rONBi_ikCFCfsEAK0WLl3j-9co=.59c8f460-58ee-4d97-bdca-24d539de95ca@github.com>
Message-ID: <mO8s4DiGTXDeY55pa3ccFDFP12zljXSi_CLS5eSl4hI=.cd93e1b3-be1c-4334-80ec-5002ab641fd5@github.com>

On Thu, 8 Jun 2023 21:42:24 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> The accessor methods in constantpool.cpp were previously cleaned up to allow for different types of indices to be used, distinguishing them by the bytecode. This patch adds the same changes to the hotspot serviceability code. Verified with tier 1-5 tests.

Marked as reviewed by fparain (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14385#pullrequestreview-1472650636

From cjplummer at openjdk.org  Fri Jun  9 17:35:44 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 9 Jun 2023 17:35:44 GMT
Subject: RFR: JDK-8309549:
 com/sun/tools/attach/warnings/DynamicLoadWarningTest.java fails on AIX
In-Reply-To: <f2Em33V-PEu68TZ9jU2b0oypu9Q5aGcw1ma-iwS8SLk=.22c2b252-38d7-4070-9d78-89d231bec6f7@github.com>
References: <f2Em33V-PEu68TZ9jU2b0oypu9Q5aGcw1ma-iwS8SLk=.22c2b252-38d7-4070-9d78-89d231bec6f7@github.com>
Message-ID: <LUjsslxWWY8dKjsEvkOQxz3tIJp0OeSCfJ1br6vwk2k=.7de8eef7-37ad-4e92-a513-cd89efe9da9b@github.com>

On Fri, 9 Jun 2023 13:39:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On AIX ,  new jtreg test  com/sun/tools/attach/warnings/DynamicLoadWarningTest.java always failed  with the output :
> 
> ----------System.err:(294/28579)----------
> STARTED DynamicLoadWarningTest::testLoadJavaAgent 'testLoadJavaAgent()'
> SUCCESSFUL DynamicLoadWarningTest::testLoadJavaAgent 'testLoadJavaAgent()'
> STARTED DynamicLoadWarningTest::testLoadOneJvmtiAgent '[1] DynamicLoadWarningTest$$Lambda/0x000000040020bd88 at 600d90bb'
> org.opentest4j.AssertionFailedError: expected: <1> but was: <2>
> at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
> at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
> at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145)
> at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:528)
> at DynamicLoadWarningTest$AppRunner.stderrShouldContain(DynamicLoadWarningTest.java:298)
> at DynamicLoadWarningTest.testLoadOneJvmtiAgent(DynamicLoadWarningTest.java:125)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> 
> Reason seems to be the different behavior of dlopen on AIX compared to e.g. Linux 
> This is what I find in the manpage of AIX 7.2 or 7.3 :
> https://www.ibm.com/docs/en/aix/7.2?topic=d-dlopen-subroutine
> https://www.ibm.com/docs/en/aix/7.3?topic=d-dlopen-subroutine
> 'If the module is already loaded, it is not loaded again, but a new, unique value will be returned by the dlopen subroutine.'
> 
> Sounds different to what Linux documents in the manpage:
> https://man7.org/linux/man-pages/man3/dlopen.3.html
> 'If the same shared object is opened again with dlopen(), the same object handle is returned.'
> 
> We skip this special subtest on AIX .

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14393#pullrequestreview-1472750566

From cjplummer at openjdk.org  Fri Jun  9 18:11:41 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 9 Jun 2023 18:11:41 GMT
Subject: RFR: 8232839: JDI AfterThreadDeathTest.java failed due to
 "FAILED: Did not get expected IllegalThreadStateException on a
 StepRequest.enable()"
In-Reply-To: <m1pRv9k7_76AZd_GEgPWd3YTrKJuDi_EClmi7s-vNJs=.61e06dcc-7e8f-4683-bebd-3c9305c308e4@github.com>
References: <m1pRv9k7_76AZd_GEgPWd3YTrKJuDi_EClmi7s-vNJs=.61e06dcc-7e8f-4683-bebd-3c9305c308e4@github.com>
Message-ID: <JrM_fdF5Ffoa_0ZToxUGwvZeS_RN5zS91pyUKear04g=.7f0a1d20-3443-4f0b-9b1a-1eb838f2d3a6@github.com>

On Wed, 7 Jun 2023 23:17:18 GMT, Chris Plummer <cjplummer at openjdk.org> 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.

thanks for the reviews Kevin and Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/14372#issuecomment-1584951868

From cjplummer at openjdk.org  Fri Jun  9 18:11:42 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 9 Jun 2023 18:11:42 GMT
Subject: Integrated: 8232839: JDI AfterThreadDeathTest.java failed due to
 "FAILED: Did not get expected IllegalThreadStateException on a
 StepRequest.enable()"
In-Reply-To: <m1pRv9k7_76AZd_GEgPWd3YTrKJuDi_EClmi7s-vNJs=.61e06dcc-7e8f-4683-bebd-3c9305c308e4@github.com>
References: <m1pRv9k7_76AZd_GEgPWd3YTrKJuDi_EClmi7s-vNJs=.61e06dcc-7e8f-4683-bebd-3c9305c308e4@github.com>
Message-ID: <WDQ-Hi1SJW_OWOc_NZ6qkR80ky3sCXV38QPqLD9DrVI=.2a643c3d-701c-4732-ba18-a6a482e2e126@github.com>

On Wed, 7 Jun 2023 23:17:18 GMT, Chris Plummer <cjplummer at openjdk.org> 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.

This pull request has now been integrated.

Changeset: 84184f94
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/84184f947342fd1adbe4e3f2230ce3de4ae6007e
Stats:     24 lines in 2 files changed: 11 ins; 3 del; 10 mod

8232839: JDI AfterThreadDeathTest.java failed due to "FAILED: Did not get expected IllegalThreadStateException on a StepRequest.enable()"

Reviewed-by: sspitsyn, kevinw

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

PR: https://git.openjdk.org/jdk/pull/14372

From matsaave at openjdk.org  Fri Jun  9 18:14:18 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 9 Jun 2023 18:14:18 GMT
Subject: RFR: 8309673: Refactor ref_at methods in Serviceability
 ConstantPool [v2]
In-Reply-To: <hRsZfM8S0Lm5YNnE-rONBi_ikCFCfsEAK0WLl3j-9co=.59c8f460-58ee-4d97-bdca-24d539de95ca@github.com>
References: <hRsZfM8S0Lm5YNnE-rONBi_ikCFCfsEAK0WLl3j-9co=.59c8f460-58ee-4d97-bdca-24d539de95ca@github.com>
Message-ID: <bU7uTxj1kx5X-ketdVfObjdvs8TcOZpPDJpRU9QtMzw=.cd115dd7-0f1a-4260-9331-6585bf10fcf3@github.com>

> The accessor methods in constantpool.cpp were previously cleaned up to allow for different types of indices to be used, distinguishing them by the bytecode. This patch adds the same changes to the hotspot serviceability agent code. Verified with tier 1-5 tests.

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Removed unnecessary assignment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14385/files
  - new: https://git.openjdk.org/jdk/pull/14385/files/2ee60bd1..6630cb2c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14385&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14385&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14385.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14385/head:pull/14385

PR: https://git.openjdk.org/jdk/pull/14385

From iklam at openjdk.org  Fri Jun  9 19:06:44 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 9 Jun 2023 19:06:44 GMT
Subject: RFR: 8309673: Refactor ref_at methods in SA ConstantPool [v2]
In-Reply-To: <bU7uTxj1kx5X-ketdVfObjdvs8TcOZpPDJpRU9QtMzw=.cd115dd7-0f1a-4260-9331-6585bf10fcf3@github.com>
References: <hRsZfM8S0Lm5YNnE-rONBi_ikCFCfsEAK0WLl3j-9co=.59c8f460-58ee-4d97-bdca-24d539de95ca@github.com>
 <bU7uTxj1kx5X-ketdVfObjdvs8TcOZpPDJpRU9QtMzw=.cd115dd7-0f1a-4260-9331-6585bf10fcf3@github.com>
Message-ID: <vQNtrlGA38c-3cQwEwN0P2sn9BrSTRMdgcACluWVqBc=.c06a808b-4386-4435-9c01-86ba7f3fdd6f@github.com>

On Fri, 9 Jun 2023 18:14:18 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> The accessor methods in constantpool.cpp were previously cleaned up to allow for different types of indices to be used, distinguishing them by the bytecode. This patch adds the same changes to the hotspot serviceability agent code. Verified with tier 1-5 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unnecessary assignment

LGTM. I would suggest changing "Serviceability" in the title to "SA"

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14385#pullrequestreview-1472921430

From matsaave at openjdk.org  Fri Jun  9 19:10:51 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 9 Jun 2023 19:10:51 GMT
Subject: Integrated: 8309673: Refactor ref_at methods in SA ConstantPool
In-Reply-To: <hRsZfM8S0Lm5YNnE-rONBi_ikCFCfsEAK0WLl3j-9co=.59c8f460-58ee-4d97-bdca-24d539de95ca@github.com>
References: <hRsZfM8S0Lm5YNnE-rONBi_ikCFCfsEAK0WLl3j-9co=.59c8f460-58ee-4d97-bdca-24d539de95ca@github.com>
Message-ID: <gybEq9gXLB69TX1DID-e73SVHLs3wDYoPJ-_1GWeatU=.29aea071-eaa9-437e-a7a3-70fee2629818@github.com>

On Thu, 8 Jun 2023 21:42:24 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> The accessor methods in constantpool.cpp were previously cleaned up to allow for different types of indices to be used, distinguishing them by the bytecode. This patch adds the same changes to the hotspot serviceability agent code. Verified with tier 1-5 tests.

This pull request has now been integrated.

Changeset: 7d6f97d0
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7d6f97d04d8fac44b9c71ec7e36c27ec61e82445
Stats:     95 lines in 4 files changed: 32 ins; 25 del; 38 mod

8309673: Refactor ref_at methods in SA ConstantPool

Reviewed-by: coleenp, fparain, iklam

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

PR: https://git.openjdk.org/jdk/pull/14385

From matsaave at openjdk.org  Fri Jun  9 19:10:49 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 9 Jun 2023 19:10:49 GMT
Subject: RFR: 8309673: Refactor ref_at methods in SA ConstantPool [v2]
In-Reply-To: <xj-YcgJatlXR3rvB04VyndSzRw5UgzzzNONwbwKj37A=.9b4822eb-0283-49d6-a478-d42e71dd7836@github.com>
References: <hRsZfM8S0Lm5YNnE-rONBi_ikCFCfsEAK0WLl3j-9co=.59c8f460-58ee-4d97-bdca-24d539de95ca@github.com>
 <xj-YcgJatlXR3rvB04VyndSzRw5UgzzzNONwbwKj37A=.9b4822eb-0283-49d6-a478-d42e71dd7836@github.com>
Message-ID: <Jk2HhC7koSKC4ox63X3p8GPnr1fFZjDvxbzHIWflSJA=.c4fe7fbb-608f-4a2a-892b-6bbb22a36311@github.com>

On Fri, 9 Jun 2023 14:56:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed unnecessary assignment
>
> Looks good.

Thank you for the reviews @coleenp, @fparain, and @iklam !

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

PR Comment: https://git.openjdk.org/jdk/pull/14385#issuecomment-1585021327

From sspitsyn at openjdk.org  Fri Jun  9 19:25:39 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 9 Jun 2023 19:25:39 GMT
Subject: RFR: JDK-8309549:
 com/sun/tools/attach/warnings/DynamicLoadWarningTest.java fails on AIX
In-Reply-To: <f2Em33V-PEu68TZ9jU2b0oypu9Q5aGcw1ma-iwS8SLk=.22c2b252-38d7-4070-9d78-89d231bec6f7@github.com>
References: <f2Em33V-PEu68TZ9jU2b0oypu9Q5aGcw1ma-iwS8SLk=.22c2b252-38d7-4070-9d78-89d231bec6f7@github.com>
Message-ID: <Tqcm_HOK2jRm3LZlJGctO4oyvkygAuz2Yx07fbG2g-M=.1476c101-f5db-4a5f-9b4f-35834c2215ae@github.com>

On Fri, 9 Jun 2023 13:39:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On AIX ,  new jtreg test  com/sun/tools/attach/warnings/DynamicLoadWarningTest.java always failed  with the output :
> 
> ----------System.err:(294/28579)----------
> STARTED DynamicLoadWarningTest::testLoadJavaAgent 'testLoadJavaAgent()'
> SUCCESSFUL DynamicLoadWarningTest::testLoadJavaAgent 'testLoadJavaAgent()'
> STARTED DynamicLoadWarningTest::testLoadOneJvmtiAgent '[1] DynamicLoadWarningTest$$Lambda/0x000000040020bd88 at 600d90bb'
> org.opentest4j.AssertionFailedError: expected: <1> but was: <2>
> at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
> at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
> at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145)
> at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:528)
> at DynamicLoadWarningTest$AppRunner.stderrShouldContain(DynamicLoadWarningTest.java:298)
> at DynamicLoadWarningTest.testLoadOneJvmtiAgent(DynamicLoadWarningTest.java:125)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> 
> Reason seems to be the different behavior of dlopen on AIX compared to e.g. Linux 
> This is what I find in the manpage of AIX 7.2 or 7.3 :
> https://www.ibm.com/docs/en/aix/7.2?topic=d-dlopen-subroutine
> https://www.ibm.com/docs/en/aix/7.3?topic=d-dlopen-subroutine
> 'If the module is already loaded, it is not loaded again, but a new, unique value will be returned by the dlopen subroutine.'
> 
> Sounds different to what Linux documents in the manpage:
> https://man7.org/linux/man-pages/man3/dlopen.3.html
> 'If the same shared object is opened again with dlopen(), the same object handle is returned.'
> 
> We skip this special subtest on AIX .

Looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14393#pullrequestreview-1472948256

From cjplummer at openjdk.org  Fri Jun  9 23:38:22 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 9 Jun 2023 23:38:22 GMT
Subject: RFR: 8309752: com/sun/jdi/SetLocalWhileThreadInNative.java fails with
 virtual test thread factory due to OpaqueFrameException
Message-ID: <iZrKNMLnyR3t5VxI-FQ7xQq9qlzWVhveKXSm-ylMA0U=.b7b289db-c3dc-4fc0-b302-af5917c611f8@github.com>

com/sun/jdi/SetLocalWhileThreadInNative.java is failing with OpaqueFrameException when using the virtual test thread factory. The reason is because JDI only supports calling StackFrame.setValue() on the topmost frame of a virtual thread. The test is calling it on the ThreadReference.frames(2), so the OpaqueFrameException is correct behavior and the test needs to adapt.

I could have chosen to just not have this test support running on a virtual thread, but it appears to be the only test we have that attempts StackFrame.setValue() on something other than the topmost frame, so it's good to have it expect the OpaqueFrameException.

Tested locally with and without the virtual thread wrapper. tier1 and tier5 svc testing tbd.

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

Commit messages:
 - Fix jcheck error
 - Expect OpaqueFrameException when using virtual threads.

Changes: https://git.openjdk.org/jdk/pull/14402/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14402&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309752
  Stats: 11 lines in 2 files changed: 7 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14402.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14402/head:pull/14402

PR: https://git.openjdk.org/jdk/pull/14402

From cjplummer at openjdk.org  Sat Jun 10 00:05:48 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 10 Jun 2023 00:05:48 GMT
Subject: RFR: 8309757: com/sun/jdi/ReferrersTest.java fails with virtual test
 thread factor
Message-ID: <XJFnWkbx07iP9gyqD9g7g9xbIljRWAPoAYQW8aoDopg=.7f9e59c5-a11c-43a1-ab5d-f5cad0956f89@github.com>

This test launches a debuggee, which creates 11 instances of its main class, stores them in a static array of the main class, and then the debugger side iterates over all referrers to the main class instaces. Usually this is a pretty quick process and doesn't produce much in the way of output while walking the reference tree of referrers. However, with virtual threads the tree walking and output get unwieldy, and eventually it fails with:


IOException reading output of child java interpreter:Stream closed
java.lang.IllegalThreadStateException
at jdk.jdi/com.sun.tools.jdi.JDWPException.toJDIException(JDWPException.java:76)
at jdk.jdi/com.sun.tools.jdi.ThreadReferenceImpl.name(ThreadReferenceImpl.java:197)
at jdk.jdi/com.sun.tools.jdi.ThreadReferenceImpl.toString(ThreadReferenceImpl.java:637)
at java.base/java.lang.String.valueOf(String.java:4461)
at ReferrersTest.showReferrers(ReferrersTest.java:438)
at ReferrersTest.showReferrers(ReferrersTest.java:466)


And ReferrersTest.showReferrers() has recursed about 200 levels deep. I'm not sure the order of these errors can be relied on. It looks like while walking the referrers tree, the test eventually stumbled upon a thread that had exited (but its Thread object was still alive), and this resulted in the test aborting. If I catch these exceptions, eventually the test times out while still working on referrers.

Judging by some of the output, it appears that introducing the TestScaffold class as a referrer to the main debuggee class is the root cause of all these extra referrers.

The test has a provision to cut off the recursion:


        // We have to stop going up a referrer chain in some cases
        Type rt = objRef.type();
        if (rt instanceof ClassType) {
            ClassType ct = (ClassType)rt;
            String name = ct.name();
            if (name.equals("sun.awt.SoftCache$ValueCell")) {
                return;
            }
            if (name.equals("java.lang.ref.Finalizer")) {
                return;
            }
            if (name.equals("java.lang.ref.SoftReference")) {
                return;
            }
            // oh oh, should really check for a subclass of ClassLoader :-)
            if (name.indexOf("ClassLoader") >= 0) {
                return;
            }
            // No doubt there are other reasons to stop ...
        }


Adding TestScaffold to the list makes it so the referrer tree walking output is almost identical to what it is when not using virtual threads. Adding java.lang.reflect.Method instead does a slightly better job.

Tested locally with and without the virtual thread wrapper. tier1 and tier5 svc testing tbd.

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

Commit messages:
 - Do some additional pruning needed when run with a virtual thread

Changes: https://git.openjdk.org/jdk/pull/14405/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14405&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309757
  Stats: 5 lines in 2 files changed: 3 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14405.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14405/head:pull/14405

PR: https://git.openjdk.org/jdk/pull/14405

From sspitsyn at openjdk.org  Sat Jun 10 02:07:50 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 10 Jun 2023 02:07:50 GMT
Subject: RFR: 8309752: com/sun/jdi/SetLocalWhileThreadInNative.java fails
 with virtual test thread factory due to OpaqueFrameException
In-Reply-To: <iZrKNMLnyR3t5VxI-FQ7xQq9qlzWVhveKXSm-ylMA0U=.b7b289db-c3dc-4fc0-b302-af5917c611f8@github.com>
References: <iZrKNMLnyR3t5VxI-FQ7xQq9qlzWVhveKXSm-ylMA0U=.b7b289db-c3dc-4fc0-b302-af5917c611f8@github.com>
Message-ID: <hifl3HKs9eBPXJ4a2mtvbjJTZRWwxTulfeT_XKS-_iI=.98551b5c-4e52-4f59-a8a0-062785cd3d79@github.com>

On Fri, 9 Jun 2023 20:47:13 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> com/sun/jdi/SetLocalWhileThreadInNative.java is failing with OpaqueFrameException when using the virtual test thread factory. The reason is because JDI only supports calling StackFrame.setValue() on the topmost frame of a virtual thread. The test is calling it on the ThreadReference.frames(2), so the OpaqueFrameException is correct behavior and the test needs to adapt.
> 
> I could have chosen to just not have this test support running on a virtual thread, but it appears to be the only test we have that attempts StackFrame.setValue() on something other than the topmost frame, so it's good to have it expect the OpaqueFrameException.
> 
> Tested locally with and without the virtual thread wrapper. tier1 and tier5 svc testing tbd.

Looks good.
Thanks,
Serguei

test/jdk/com/sun/jdi/SetLocalWhileThreadInNative.java line 166:

> 164:         List<LocalVariable> localVars = frame.visibleVariables();
> 165:         boolean changedLocal = false;
> 166:         boolean caughtOPE = false;

Nit: Should it be caughtOFE instead of caughtOPE?

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14402#pullrequestreview-1473268372
PR Review Comment: https://git.openjdk.org/jdk/pull/14402#discussion_r1224999636

From cjplummer at openjdk.org  Sat Jun 10 02:56:47 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 10 Jun 2023 02:56:47 GMT
Subject: RFR: 8309752: com/sun/jdi/SetLocalWhileThreadInNative.java fails
 with virtual test thread factory due to OpaqueFrameException [v2]
In-Reply-To: <iZrKNMLnyR3t5VxI-FQ7xQq9qlzWVhveKXSm-ylMA0U=.b7b289db-c3dc-4fc0-b302-af5917c611f8@github.com>
References: <iZrKNMLnyR3t5VxI-FQ7xQq9qlzWVhveKXSm-ylMA0U=.b7b289db-c3dc-4fc0-b302-af5917c611f8@github.com>
Message-ID: <ZxTOsMa53WppA3IORT8fUzLmCB-ucy74euRgXvXi-J0=.690b4416-5ecd-474e-85c5-527801a89af0@github.com>

> com/sun/jdi/SetLocalWhileThreadInNative.java is failing with OpaqueFrameException when using the virtual test thread factory. The reason is because JDI only supports calling StackFrame.setValue() on the topmost frame of a virtual thread. The test is calling it on the ThreadReference.frames(2), so the OpaqueFrameException is correct behavior and the test needs to adapt.
> 
> I could have chosen to just not have this test support running on a virtual thread, but it appears to be the only test we have that attempts StackFrame.setValue() on something other than the topmost frame, so it's good to have it expect the OpaqueFrameException.
> 
> Tested locally with and without the virtual thread wrapper. tier1 and tier5 svc testing tbd.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  caughtOPE -> caughtOFE

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14402/files
  - new: https://git.openjdk.org/jdk/pull/14402/files/ee21d434..2799ebe6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14402&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14402&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14402.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14402/head:pull/14402

PR: https://git.openjdk.org/jdk/pull/14402

From asemenov at openjdk.org  Sun Jun 11 15:40:28 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Sun, 11 Jun 2023 15:40:28 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v3]
In-Reply-To: <xZ74zHbqffVTsEOGXk2t1cSOOG1uX9fZ6CruSac9U4k=.79254c0b-1947-4911-bdbc-5abae651e950@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <CKiRtl0qFJAta3S3Ysa1wQHfQI34FDAW6qLvb8p336U=.2f3cfe22-b050-4483-b95b-b53aa8e2e78d@github.com>
 <XCV9wPHhv83rnla_Y8LoBYJ9EdcQfuAlClsvp01vHdg=.d8982ce2-253e-4ba5-93f5-ca12c489c38b@github.com>
 <CnZGN1jj91T015K1ywlKfrv0xj-eRKVJMd2iayTSXWg=.a6386461-e844-480a-b351-901cfb945be5@github.com>
 <A6_DjU6Oy1FQ2jv01AAzEvvtbwyIZzbqhrc-qG-Lfh8=.b6ee5527-f523-42b6-ae40-f7c14ee797f7@github.com>
 <kVqgGub33GeB4hq2vRW7vxiObaD_DbXICbsv8-NoFiU=.aaf4825e-d820-496d-8faa-cede92c21323@github.com>
 <xZ74zHbqffVTsEOGXk2t1cSOOG1uX9fZ6CruSac9U4k=.79254c0b-1947-4911-bdbc-5abae651e950@github.com>
Message-ID: <eBtSHGuk6jA2M9fjawmCo9mpiqkzcvZUXalngywokB0=.4f3f5cfc-45ba-4cb8-94c6-fbe843201879@github.com>

On Tue, 6 Jun 2023 17:47:02 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This is rarely used in the code and is not the essence of the current changes.
>> If you introduce such changes, then throughout the code.
>> Moreover, this can lead to problems, such as, for example, here: https://bugs.openjdk.org/browse/JDK-8309225
>
> I'm not a clang expect, I was just asking if modifying the current `#if TARGET_OS_MAC` check into `#if defined(__APPLE__)` is also a solution. The comment on lines 46-47 says the condition was copied from a macOS SDK file and that's what the file is using now.

I think you can create a separate ticket and pull request to discuss this issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1225842637

From asemenov at openjdk.org  Sun Jun 11 16:38:31 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Sun, 11 Jun 2023 16:38:31 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v5]
In-Reply-To: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
Message-ID: <uTI-0-FTTOiVf6_6psxvUks06Xj57078fd8yzoUkb5E=.d0f3deb0-8199-46fc-b259-18d41ad3cbbb@github.com>

> 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 with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - update
 - update
 - update
 - update
 - 8308286 Fix clang warnings in linux code

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

Changes: https://git.openjdk.org/jdk/pull/14033/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=04
  Stats: 16 lines in 6 files changed: 14 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14033.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14033/head:pull/14033

PR: https://git.openjdk.org/jdk/pull/14033

From lmesnik at openjdk.org  Sun Jun 11 18:16:28 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sun, 11 Jun 2023 18:16:28 GMT
Subject: RFR: 8309752: com/sun/jdi/SetLocalWhileThreadInNative.java fails
 with virtual test thread factory due to OpaqueFrameException [v2]
In-Reply-To: <ZxTOsMa53WppA3IORT8fUzLmCB-ucy74euRgXvXi-J0=.690b4416-5ecd-474e-85c5-527801a89af0@github.com>
References: <iZrKNMLnyR3t5VxI-FQ7xQq9qlzWVhveKXSm-ylMA0U=.b7b289db-c3dc-4fc0-b302-af5917c611f8@github.com>
 <ZxTOsMa53WppA3IORT8fUzLmCB-ucy74euRgXvXi-J0=.690b4416-5ecd-474e-85c5-527801a89af0@github.com>
Message-ID: <EHOCyRGIxHbuFUkKWWPWOczCFve52OHlLVNdklbhz8A=.829cbd76-963f-4eaa-b20c-24f1bb9d504a@github.com>

On Sat, 10 Jun 2023 02:56:47 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> com/sun/jdi/SetLocalWhileThreadInNative.java is failing with OpaqueFrameException when using the virtual test thread factory. The reason is because JDI only supports calling StackFrame.setValue() on the topmost frame of a virtual thread. The test is calling it on the ThreadReference.frames(2), so the OpaqueFrameException is correct behavior and the test needs to adapt.
>> 
>> I could have chosen to just not have this test support running on a virtual thread, but it appears to be the only test we have that attempts StackFrame.setValue() on something other than the topmost frame, so it's good to have it expect the OpaqueFrameException.
>> 
>> Tested locally with and without the virtual thread wrapper. tier1 and tier5 svc testing tbd.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   caughtOPE -> caughtOFE

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14402#pullrequestreview-1473772526

From yyang at openjdk.org  Mon Jun 12 06:34:06 2023
From: yyang at openjdk.org (Yi Yang)
Date: Mon, 12 Jun 2023 06:34:06 GMT
Subject: RFR: JDK-8306441: Two-stage Segmented Heap Dump [v5]
In-Reply-To: <ND9kZgFWcpvUXuGAvet3P_ZogisHGeBtlp25Bs0yq54=.40f4bb74-860e-4da4-8fcb-219a9f8d1268@github.com>
References: <8YqPPHSW4K1s0t317Kp6UqvoGuv5v9oCbjtQ9FX8p2o=.0f6c687b-d031-401d-901d-1ec532715cdc@github.com>
 <wNQyKkNDDiJASas3cYcqFnivt88Zx75VSMxr4YWeUwE=.751ca007-5117-4bb1-aacf-561498d6f5f8@github.com>
 <P16t1xi9eYl0bNjMUlxj9RJ-Qc4n9wnAmOMGWm-akwY=.93176665-7be1-48d5-826f-cc3e3a8f63ce@github.com>
 <ND9kZgFWcpvUXuGAvet3P_ZogisHGeBtlp25Bs0yq54=.40f4bb74-860e-4da4-8fcb-219a9f8d1268@github.com>
Message-ID: <gi4FFuwPTXC09olallMip99aint63uzp3DEJbN9MfRk=.5566e5ff-a1fe-4f76-9dfd-395f22098d46@github.com>

On Tue, 16 May 2023 18:41:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Hi, can I have a review for this patch?
>
> @y1yang0 Sorry no one has been able to review this so far. The serviceability team is very busy for the next few weeks finishing up JDK 21 changes before RDP1. It's unlikely we'll find time for the review before them.
> 
> I did take a very quick look at the changes just to understand the scope. One thing I noticed that makes this PR hard to review is the code refactoring and relocating that you did. At first it looks like a lot of old code was deleted and a lot of new code added, but in fact most of the new code is just relocated old code. It makes it very hard to tell if there have been any changes to this code. Is there anything you can do to lessen the amount of apparent new code that is actually just moved code?

Hi @plummercj @kevinjwalls @alexmenkov, sorry to disturb you. RDP1 has ended. Do you have any plans to review this patch recently? Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/13667#issuecomment-1586671507

From mbaesken at openjdk.org  Mon Jun 12 07:10:57 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 12 Jun 2023 07:10:57 GMT
Subject: Integrated: JDK-8309549:
 com/sun/tools/attach/warnings/DynamicLoadWarningTest.java fails on AIX
In-Reply-To: <f2Em33V-PEu68TZ9jU2b0oypu9Q5aGcw1ma-iwS8SLk=.22c2b252-38d7-4070-9d78-89d231bec6f7@github.com>
References: <f2Em33V-PEu68TZ9jU2b0oypu9Q5aGcw1ma-iwS8SLk=.22c2b252-38d7-4070-9d78-89d231bec6f7@github.com>
Message-ID: <m7gB3eS77Ud8qStzt2DfZ-h-X5lZG7zGVCfVDcOlL9g=.1338427b-7900-4592-bde5-ec97a6085b4b@github.com>

On Fri, 9 Jun 2023 13:39:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On AIX ,  new jtreg test  com/sun/tools/attach/warnings/DynamicLoadWarningTest.java always failed  with the output :
> 
> ----------System.err:(294/28579)----------
> STARTED DynamicLoadWarningTest::testLoadJavaAgent 'testLoadJavaAgent()'
> SUCCESSFUL DynamicLoadWarningTest::testLoadJavaAgent 'testLoadJavaAgent()'
> STARTED DynamicLoadWarningTest::testLoadOneJvmtiAgent '[1] DynamicLoadWarningTest$$Lambda/0x000000040020bd88 at 600d90bb'
> org.opentest4j.AssertionFailedError: expected: <1> but was: <2>
> at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
> at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
> at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145)
> at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:528)
> at DynamicLoadWarningTest$AppRunner.stderrShouldContain(DynamicLoadWarningTest.java:298)
> at DynamicLoadWarningTest.testLoadOneJvmtiAgent(DynamicLoadWarningTest.java:125)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> 
> Reason seems to be the different behavior of dlopen on AIX compared to e.g. Linux 
> This is what I find in the manpage of AIX 7.2 or 7.3 :
> https://www.ibm.com/docs/en/aix/7.2?topic=d-dlopen-subroutine
> https://www.ibm.com/docs/en/aix/7.3?topic=d-dlopen-subroutine
> 'If the module is already loaded, it is not loaded again, but a new, unique value will be returned by the dlopen subroutine.'
> 
> Sounds different to what Linux documents in the manpage:
> https://man7.org/linux/man-pages/man3/dlopen.3.html
> 'If the same shared object is opened again with dlopen(), the same object handle is returned.'
> 
> We skip this special subtest on AIX .

This pull request has now been integrated.

Changeset: 4d66d977
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4d66d977450e083214da3dba6ad4ed851c6c1cb4
Stats:     7 lines in 1 file changed: 3 ins; 0 del; 4 mod

8309549: com/sun/tools/attach/warnings/DynamicLoadWarningTest.java fails on AIX

Reviewed-by: alanb, cjplummer, sspitsyn

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

PR: https://git.openjdk.org/jdk/pull/14393

From duke at openjdk.org  Mon Jun 12 10:04:05 2023
From: duke at openjdk.org (JoKern65)
Date: Mon, 12 Jun 2023 10:04:05 GMT
Subject: Integrated: JDK-8309462: [AIX]
 vmTestbase/nsk/jvmti/RunAgentThread/agentthr001/TestDescription.java crashing
 due to empty while loop
In-Reply-To: <XLSnFyCggsHJL-YGgwO1icLhcDc-gFX98AR3NR8wB0Y=.024c3b61-79d2-42a6-a38e-517233c23091@github.com>
References: <XLSnFyCggsHJL-YGgwO1icLhcDc-gFX98AR3NR8wB0Y=.024c3b61-79d2-42a6-a38e-517233c23091@github.com>
Message-ID: <6FqRlF1qvten3FMAVitnVXbHIAH2PGT8r__lviVrDUE=.15db8952-297e-4613-9fe1-49a53261febe@github.com>

On Tue, 6 Jun 2023 09:51:09 GMT, JoKern65 <duke at openjdk.org> 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 <unistd.h>`
> `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) {`
> `     }`
> `}`

This pull request has now been integrated.

Changeset: cf9e6353
Author:    JoKern65 <Joachim.kern at sap.com>
Committer: Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cf9e6353cc6fe9e57a7a9883813d09892e7e7621
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8309462: [AIX] vmTestbase/nsk/jvmti/RunAgentThread/agentthr001/TestDescription.java crashing due to empty while loop

Reviewed-by: mbaesken, mdoerr, clanger

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

PR: https://git.openjdk.org/jdk/pull/14330

From erikj at openjdk.org  Mon Jun 12 12:30:55 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 12 Jun 2023 12:30:55 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v5]
In-Reply-To: <uTI-0-FTTOiVf6_6psxvUks06Xj57078fd8yzoUkb5E=.d0f3deb0-8199-46fc-b259-18d41ad3cbbb@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <uTI-0-FTTOiVf6_6psxvUks06Xj57078fd8yzoUkb5E=.d0f3deb0-8199-46fc-b259-18d41ad3cbbb@github.com>
Message-ID: <gsunSnFI-zLXJ0T0_foKShSTuXvUuhY0J7y-8oA-HAk=.1a6208f6-261e-49eb-8786-cd11dd2a7c31@github.com>

On Sun, 11 Jun 2023 16:38:31 GMT, Artem Semenov <asemenov at openjdk.org> 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 with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - update
>  - update
>  - update
>  - update
>  - 8308286 Fix clang warnings in linux code

Build changes look ok.

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

PR Comment: https://git.openjdk.org/jdk/pull/14033#issuecomment-1587242876

From apangin at openjdk.org  Mon Jun 12 13:00:56 2023
From: apangin at openjdk.org (Andrei Pangin)
Date: Mon, 12 Jun 2023 13:00:56 GMT
Subject: RFR: 8309271: A way to align already compiled methods with
 compiler directives
In-Reply-To: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
References: <csWpTiZu4dQgyARmNGro8PYl8yLj6-dRjVdsh51jV0k=.c0e25efd-3ee0-4196-a05a-c54268f23660@github.com>
Message-ID: <qPhUiQ3vhYAq7snNjuKQdWE884yC6ZVvacLpkbnkaHo=.1a70105e-a82a-4c01-8670-29fa9511077a@github.com>

On Wed, 24 May 2023 00:38:27 GMT, Dmitry Chuyko <dchuyko at openjdk.org> wrote:

> Compiler Control (https://openjdk.org/jeps/165) provides method-context dependent control of the JVM compilers (C1 and C2). The active directive stack is built from the directive files passed with the `-XX:CompilerDirectivesFile` diagnostic command-line option and the Compiler.add_directives diagnostic command. It is also possible to clear all directives or remove the top from the stack.
> 
> A matching directive will be applied at method compilation time when such compilation is started. If directives are added or changed, but compilation does not start, then the state of compiled methods doesn't correspond to the rules. This is not an error, and it happens in long running applications when directives are added or removed after compilation of methods that could be matched. For example, the user decides that C2 compilation needs to be disabled for some method due to a compiler bug, issues such a directive but this does not affect the application behavior. In such case, the target application needs to be restarted, and such an operation can have high costs and risks. Another goal is testing/debugging compilers.
> 
> It would be convenient to optionally reconcile at least existing matching nmethods to the current stack of compiler directives. Methods in general are often inlined, and this information is hard to track down.
> 
> Natural way to eliminate the discrepancy between the result of compilation and the broken rule is to discard the compilation result, i.e. deoptimization. Obviously there is a performance penalty, so it should be applied with care. Hot code will most likely be recompiled soon, as nothing happens to its hotness.
> 
> A new flag '`-d`' has beed introduced for some directives related to compile commands: `Compiler.add_directives`, `Compiler.remove_directives`, `Compiler.clear_directives`. The default behavior has not changed (no flag). If the new flag is present, the command scans already compiled methods and marks for deoptimization those methods that have any active non-default matching compiler directives. There is currently no distinction which directives are found. In particular, this means that if there are rules for inlining into some method, it will be deoptimized. On the other hand, if there are rules for a method and it was inlined, top-level methods won't be deoptimized, but this can be achieved by having rules for them.
> 
> In addition, a new diagnistic command `Compiler.replace_directives`, has been added for convenience. It's like a combinatio...

src/hotspot/share/code/codeCache.cpp line 1379:

> 1377:   while(iter.next()) {
> 1378:     CompiledMethod* nm = iter.method();
> 1379:     HandleMark hm(thread);

Isn't it better to move `HandleMark` outside the loop?

src/hotspot/share/runtime/mutexLocker.cpp line 274:

> 272:   MUTEX_DEFN(MethodCompileQueue_lock         , PaddedMonitor, safepoint);
> 273:   MUTEX_DEFN(CompileStatistics_lock          , PaddedMutex  , safepoint);
> 274:   MUTEX_DEFN(DirectivesStack_lock            , PaddedMutex  , nosafepoint-3);

A comment explaining the rank change would be helpful.

src/hotspot/share/services/diagnosticCommand.cpp line 890:

> 888:                            DCmdWithParser(output, heap),
> 889:   _filename("filename", "Name of the directives file", "STRING", true),
> 890:   _force_deopt("-d", "Force deoptimization of affected methods.", "BOOLEAN", false, "false") {

I agree with Paul a generic alternative like `refresh` would be better.

src/hotspot/share/services/diagnosticCommand.cpp line 946:

> 944:     DeoptimizationScope deopt_scope;
> 945:     CodeCache::mark_for_deoptimization_directives_matches(&deopt_scope);
> 946:     DirectivesStack::pop(1);

Why deoptimizing methods from the whole stack if we change only the topmost list?

src/hotspot/share/services/diagnosticCommand.hpp line 734:

> 732: };
> 733: 
> 734: class CompilerDirectivesReplaceDCmd : public DCmdWithParser {

Introducing a new command probably isn't worth it, given the same functionality can be achieved with existing commands. Furthermore, it's not obvious whether "replace" should mean remove+add or clear+add.

src/hotspot/share/services/diagnosticCommand.hpp line 745:

> 743:   }
> 744:   static const char* description() {
> 745:     return "Clear derectives stack amd load new compiler directives from file.";

Spelling: Clear *directives* stack *and* ...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14111#discussion_r1226618742
PR Review Comment: https://git.openjdk.org/jdk/pull/14111#discussion_r1226553192
PR Review Comment: https://git.openjdk.org/jdk/pull/14111#discussion_r1226624671
PR Review Comment: https://git.openjdk.org/jdk/pull/14111#discussion_r1226627598
PR Review Comment: https://git.openjdk.org/jdk/pull/14111#discussion_r1226604676
PR Review Comment: https://git.openjdk.org/jdk/pull/14111#discussion_r1226548048

From stsypanov at openjdk.org  Mon Jun 12 13:30:41 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Mon, 12 Jun 2023 13:30:41 GMT
Subject: RFR: 8309408: Thread.sleep cleanup
In-Reply-To: <aQgYdV9yETAis_U44TCaI5C5MTR4DMMD-5Li28_cbvc=.6d65e000-4b13-4f27-a7d8-e6854e99337f@github.com>
References: <aQgYdV9yETAis_U44TCaI5C5MTR4DMMD-5Li28_cbvc=.6d65e000-4b13-4f27-a7d8-e6854e99337f@github.com>
Message-ID: <UfvDL9yxr6srcg0YQPvYOzL2ZYhBlAy8Uhz228WZqHc=.7cf17196-b445-4be2-9e73-ddb3d259c017@github.com>

On Sun, 4 Jun 2023 11:28:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thread.sleep has had quite a bit of churn recently to support virtual threads, add sleep(Duration), a JFR event, and the change the underlying implementation to support sub-millis precision. I think the changes have settled down now so we can do some small cleanups that came up in PR discussions. The cleanups were kicked down the road as it requires tracking down faraway tests that depend on the stack depth and the names of internal methods. The two cleanups proposed here are:
> 
> 1.  Add a private sleepNanos method that creates/commits the JFR event around the sleep, this avoids duplicate code in the 3 sleep methods.
> 2.  Rename JVM_Sleep to JVM_SleepNanos to make it clear that it takes the sleep time in nanoseconds, esp. when Thread.sleep's parameter is milliseconds.

test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/OwnedMonitorsStackDepthInfo/ownedMonitorsStackDepthInfo001/ownedMonitorsStackDepthInfo001a.java line 113:

> 111:             return -1;
> 112:         } else {
> 113:             return depth + 2;

Doesn't it change the logic?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14303#discussion_r1226668010

From mdoerr at openjdk.org  Mon Jun 12 14:45:24 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 12 Jun 2023 14:45:24 GMT
Subject: RFR: 8309462: [AIX]
 vmTestbase/nsk/jvmti/RunAgentThread/agentthr001/TestDescription.java crashing
 due to empty while loop
Message-ID: <wt_i-ZtqoIxyQ8bxwIFMlz4BXsk-LcK2S67NTC0IVAI=.8de72b67-94b7-44da-97e5-eca5822bfada@github.com>

Test fix for test failing on AIX because of undefined behavior in current implementation.

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

Commit messages:
 - Backport cf9e6353cc6fe9e57a7a9883813d09892e7e7621

Changes: https://git.openjdk.org/jdk21/pull/9/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=9&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309462
  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk21/pull/9.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/9/head:pull/9

PR: https://git.openjdk.org/jdk21/pull/9

From mbaesken at openjdk.org  Mon Jun 12 14:49:49 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 12 Jun 2023 14:49:49 GMT
Subject: RFR: 8309462: [AIX]
 vmTestbase/nsk/jvmti/RunAgentThread/agentthr001/TestDescription.java crashing
 due to empty while loop
In-Reply-To: <wt_i-ZtqoIxyQ8bxwIFMlz4BXsk-LcK2S67NTC0IVAI=.8de72b67-94b7-44da-97e5-eca5822bfada@github.com>
References: <wt_i-ZtqoIxyQ8bxwIFMlz4BXsk-LcK2S67NTC0IVAI=.8de72b67-94b7-44da-97e5-eca5822bfada@github.com>
Message-ID: <M1MfSQcfHH1wpxQxelehSZXseE1HoGIIJSYYeGUBWGg=.c9884f9d-9deb-4c13-a371-357222cf6de7@github.com>

On Mon, 12 Jun 2023 14:36:56 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Test fix for test failing on AIX because of undefined behavior in current implementation.

Marked as reviewed by mbaesken (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/9#pullrequestreview-1475121715

From mdoerr at openjdk.org  Mon Jun 12 14:49:50 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 12 Jun 2023 14:49:50 GMT
Subject: RFR: 8309462: [AIX]
 vmTestbase/nsk/jvmti/RunAgentThread/agentthr001/TestDescription.java crashing
 due to empty while loop
In-Reply-To: <wt_i-ZtqoIxyQ8bxwIFMlz4BXsk-LcK2S67NTC0IVAI=.8de72b67-94b7-44da-97e5-eca5822bfada@github.com>
References: <wt_i-ZtqoIxyQ8bxwIFMlz4BXsk-LcK2S67NTC0IVAI=.8de72b67-94b7-44da-97e5-eca5822bfada@github.com>
Message-ID: <KX2ie4D-L-WCeRlB6O48Ou3L_nobXYYH0qiqsVgh6x8=.488b4697-7cab-4663-b443-10fbfc459691@github.com>

On Mon, 12 Jun 2023 14:36:56 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Test fix for test failing on AIX because of undefined behavior in current implementation.

Thanks for the review! I'm planning to integrate tomorrow.

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

PR Comment: https://git.openjdk.org/jdk21/pull/9#issuecomment-1587497638

From duke at openjdk.org  Mon Jun 12 17:59:12 2023
From: duke at openjdk.org (duke)
Date: Mon, 12 Jun 2023 17:59:12 GMT
Subject: Withdrawn: 8295146: Clean up native code with newer C/C++ language
 features
In-Reply-To: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
References: <h7OfjsjMR4UCdsjoU4LJiMhJdBOUCORnEtMY2vBSiII=.faa9c80c-9dc2-47b2-ab1f-e964d04be41b@github.com>
Message-ID: <B47suQ-1_XUTr22InIeSbc65c45vtVn8ZxAoALq0mdA=.0f7d7996-a97d-4931-a6b7-b02dacaea4c2@github.com>

On Thu, 10 Nov 2022 06:20:41 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ code across the JDK can be replaced and simplified with cleaner language features that were previously not available due to required compatibility with the now unsupported Visual C++ 2017 compiler. These cleanups were highlighted by the very briefly integrated 8296115
> 
> No changes to the behaviour of the JDK has resulted in any way from this commit

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/11081

From cjplummer at openjdk.org  Mon Jun 12 18:10:59 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 12 Jun 2023 18:10:59 GMT
Subject: RFR: 8309752: com/sun/jdi/SetLocalWhileThreadInNative.java fails
 with virtual test thread factory due to OpaqueFrameException [v2]
In-Reply-To: <ZxTOsMa53WppA3IORT8fUzLmCB-ucy74euRgXvXi-J0=.690b4416-5ecd-474e-85c5-527801a89af0@github.com>
References: <iZrKNMLnyR3t5VxI-FQ7xQq9qlzWVhveKXSm-ylMA0U=.b7b289db-c3dc-4fc0-b302-af5917c611f8@github.com>
 <ZxTOsMa53WppA3IORT8fUzLmCB-ucy74euRgXvXi-J0=.690b4416-5ecd-474e-85c5-527801a89af0@github.com>
Message-ID: <JLWGv3ouoK-L69UNkzkMduvJuGBUGCpA7bAct31ZUp0=.06557f47-09b4-4b11-8e36-837e8b3866af@github.com>

On Sat, 10 Jun 2023 02:56:47 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> com/sun/jdi/SetLocalWhileThreadInNative.java is failing with OpaqueFrameException when using the virtual test thread factory. The reason is because JDI only supports calling StackFrame.setValue() on the topmost frame of a virtual thread. The test is calling it on the ThreadReference.frames(2), so the OpaqueFrameException is correct behavior and the test needs to adapt.
>> 
>> I could have chosen to just not have this test support running on a virtual thread, but it appears to be the only test we have that attempts StackFrame.setValue() on something other than the topmost frame, so it's good to have it expect the OpaqueFrameException.
>> 
>> Tested locally with and without the virtual thread wrapper. tier1 and tier5 svc testing tbd.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   caughtOPE -> caughtOFE

Thanks for the reviews Leonid and Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/14402#issuecomment-1587826234

From cjplummer at openjdk.org  Mon Jun 12 18:10:59 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 12 Jun 2023 18:10:59 GMT
Subject: Integrated: 8309752: com/sun/jdi/SetLocalWhileThreadInNative.java
 fails with virtual test thread factory due to OpaqueFrameException
In-Reply-To: <iZrKNMLnyR3t5VxI-FQ7xQq9qlzWVhveKXSm-ylMA0U=.b7b289db-c3dc-4fc0-b302-af5917c611f8@github.com>
References: <iZrKNMLnyR3t5VxI-FQ7xQq9qlzWVhveKXSm-ylMA0U=.b7b289db-c3dc-4fc0-b302-af5917c611f8@github.com>
Message-ID: <VUA9dkUict42m3uSF7JFo4cln1mmpB9xBW4XE_GtS38=.1721726e-ee2e-496e-a9cd-f6c8d9dbcdd6@github.com>

On Fri, 9 Jun 2023 20:47:13 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> com/sun/jdi/SetLocalWhileThreadInNative.java is failing with OpaqueFrameException when using the virtual test thread factory. The reason is because JDI only supports calling StackFrame.setValue() on the topmost frame of a virtual thread. The test is calling it on the ThreadReference.frames(2), so the OpaqueFrameException is correct behavior and the test needs to adapt.
> 
> I could have chosen to just not have this test support running on a virtual thread, but it appears to be the only test we have that attempts StackFrame.setValue() on something other than the topmost frame, so it's good to have it expect the OpaqueFrameException.
> 
> Tested locally with and without the virtual thread wrapper. tier1 and tier5 svc testing tbd.

This pull request has now been integrated.

Changeset: 1612b6dc
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1612b6dc6e7075e1c0c82d0e92910051c8066fe5
Stats:     11 lines in 2 files changed: 7 ins; 1 del; 3 mod

8309752: com/sun/jdi/SetLocalWhileThreadInNative.java fails with virtual test thread factory due to OpaqueFrameException

Reviewed-by: sspitsyn, lmesnik

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

PR: https://git.openjdk.org/jdk/pull/14402

From iklam at openjdk.org  Mon Jun 12 20:00:19 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 12 Jun 2023 20:00:19 GMT
Subject: RFR: 8309878: Reduce inclusion of resolvedIndyEntry.hpp
Message-ID: <ngayct8s671hMXh-nM2Geo7wUpvGqDOzu4gvZr97Mzg=.b6a417c2-13f4-48e1-abef-743ac4966e6d@github.com>

resolvedIndyEntry.hpp was added in [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995) and is included in the popular cpCache.hpp. As a result, resolvedIndyEntry.hpp is included in 807 out of about 1160 hotspot .o files.

The contents of resolvedIndyEntry.hpp is infrequently used. Its inclusion should be moved from cpCache.hpp to cpCache.inline.hpp. This improves hotspot build time.

After this PR, resolvedIndyEntry.hpp is included in only 30 hotspot .o files.

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

Commit messages:
 - fixed copyright
 - step2
 - step1

Changes: https://git.openjdk.org/jdk/pull/14427/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14427&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309878
  Stats: 86 lines in 35 files changed: 61 ins; 13 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/14427.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14427/head:pull/14427

PR: https://git.openjdk.org/jdk/pull/14427

From coleenp at openjdk.org  Mon Jun 12 20:16:41 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 12 Jun 2023 20:16:41 GMT
Subject: RFR: 8309878: Reduce inclusion of resolvedIndyEntry.hpp
In-Reply-To: <ngayct8s671hMXh-nM2Geo7wUpvGqDOzu4gvZr97Mzg=.b6a417c2-13f4-48e1-abef-743ac4966e6d@github.com>
References: <ngayct8s671hMXh-nM2Geo7wUpvGqDOzu4gvZr97Mzg=.b6a417c2-13f4-48e1-abef-743ac4966e6d@github.com>
Message-ID: <sK5uT0PVftexOFxH4fQvpcbLTXbnxOKFqFWewqr--aQ=.f00fd795-b0bf-4b23-b5a3-c14866240396@github.com>

On Mon, 12 Jun 2023 19:52:36 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> resolvedIndyEntry.hpp was added in [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995) and is included in the popular cpCache.hpp. As a result, resolvedIndyEntry.hpp is included in 807 out of about 1160 hotspot .o files.
> 
> The contents of resolvedIndyEntry.hpp is infrequently used. Its inclusion should be moved from cpCache.hpp to cpCache.inline.hpp. This improves hotspot build time.
> 
> After this PR, resolvedIndyEntry.hpp is included in only 30 hotspot .o files.

Marked as reviewed by coleenp (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14427#pullrequestreview-1475737898

From jlu at openjdk.org  Mon Jun 12 21:28:30 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 21:28:30 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
Message-ID: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>

Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).

To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 

For example,

<img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">


Please note that the HTML files only apply to .properties, and not .java resources.

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

Commit messages:
 - Revert tool's un-translation of 'exception-type' for zh-CN
 - Move localized currencynames.properties to jdk.localedata
 - Apply trailing WS tool patch
 - Remove extra quotes in 'main.usage' values
 - Revert WinResources changing of 'resource.wxl-file-name' value
 - Revert MsiInstallerStrings culture value changes
 - Apply JDK21 Open translation patch

Changes: https://git.openjdk.org/jdk21/pull/11/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=11&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309632
  Stats: 462 lines in 51 files changed: 279 ins; 48 del; 135 mod
  Patch: https://git.openjdk.org/jdk21/pull/11.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/11/head:pull/11

PR: https://git.openjdk.org/jdk21/pull/11

From jlu at openjdk.org  Mon Jun 12 21:28:30 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 21:28:30 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
Message-ID: <-g_p5DXIJa2iFx-wYX9Fl024cy_wOxNlIN3g8TB5V1E=.84d95609-9341-4a50-afa2-e9dcb462a0bb@github.com>

On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

@naotoj @wangweij @sormuras could you please review the changes that affect the languages you are familiar with when you have the chance. Please use the HTML files for this, as they will be in UTF-8 native and not unicode escaped sequences.

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

PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1588123540

From jlu at openjdk.org  Mon Jun 12 21:29:54 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 21:29:54 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
Message-ID: <n6j_chC6_ocXcwoUifnCegPxC9WyUJ-qxmIOwIOtSbc=.7959914d-cf42-4dc9-9bc7-c22805752df2@github.com>

On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

@prrace @jonathan-gibbons @pavelrappo @lahodaj @wangweij @igraves @AlanBateman @eirbjo could you please review the modules / changes you are familiar with, thank you.

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

PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1588130775

From kcr at openjdk.org  Mon Jun 12 21:45:55 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 12 Jun 2023 21:45:55 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <n6j_chC6_ocXcwoUifnCegPxC9WyUJ-qxmIOwIOtSbc=.7959914d-cf42-4dc9-9bc7-c22805752df2@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
 <n6j_chC6_ocXcwoUifnCegPxC9WyUJ-qxmIOwIOtSbc=.7959914d-cf42-4dc9-9bc7-c22805752df2@github.com>
Message-ID: <XLQRlN-K1DkMS8uDHHMub6X4-dD88ddD55WPBuNOyZM=.59c1a2dd-3ab4-4b89-ac42-5d4460447f54@github.com>

On Mon, 12 Jun 2023 21:27:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
>> 
>> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
>> 
>> For example,
>> 
>> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
>> 
>> 
>> Please note that the HTML files only apply to .properties, and not .java resources.
>
> @prrace @jonathan-gibbons @pavelrappo @lahodaj @wangweij @igraves @AlanBateman @eirbjo could you please review the modules / changes you are familiar with, thank you.

@justin-curtis-lu Unless there is a strong reason to do otherwise, Please submit a PR against jdk mainline first. Then, once that is integrated, you can proceed with this PR as a backport to JDK 21.

See: https://mail.openjdk.org/pipermail/jdk-dev/2023-June/007894.html

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

PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1588146416

From jlu at openjdk.org  Mon Jun 12 21:55:48 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 21:55:48 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <XLQRlN-K1DkMS8uDHHMub6X4-dD88ddD55WPBuNOyZM=.59c1a2dd-3ab4-4b89-ac42-5d4460447f54@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
 <n6j_chC6_ocXcwoUifnCegPxC9WyUJ-qxmIOwIOtSbc=.7959914d-cf42-4dc9-9bc7-c22805752df2@github.com>
 <XLQRlN-K1DkMS8uDHHMub6X4-dD88ddD55WPBuNOyZM=.59c1a2dd-3ab4-4b89-ac42-5d4460447f54@github.com>
Message-ID: <ZVzi-lqSlf4r01XSuWXwqs8_Ku3uEGgB_f2BRDOqsvQ=.9c38d799-5e1e-4ec7-8f74-81a9603cde4d@github.com>

On Mon, 12 Jun 2023 21:42:24 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> @prrace @jonathan-gibbons @pavelrappo @lahodaj @wangweij @igraves @AlanBateman @eirbjo could you please review the modules / changes you are familiar with, thank you.
>
> @justin-curtis-lu Unless there is a strong reason to do otherwise, Please submit a PR against jdk mainline first. Then, once that is integrated, you can proceed with this PR as a backport to JDK 21.
> 
> See: https://mail.openjdk.org/pipermail/jdk-dev/2023-June/007894.html

@kevinrushforth Thanks for the reminder, will make the change in ML first.

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

PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1588156115

From jlu at openjdk.org  Mon Jun 12 22:07:11 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 22:07:11 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
Message-ID: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>

Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).

To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 

For example,

<img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">


Please note that the HTML files only apply to .properties, and not .java resources.

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

Commit messages:
 - Merge remote-tracking branch 'justinJDK21/JDK21-RDP1-L10nDrop' into JDK21-L10NDrop-RDP1
 - Revert tool's un-translation of 'exception-type' for zh-CN
 - Move localized currencynames.properties to jdk.localedata
 - Apply trailing WS tool patch
 - Remove extra quotes in 'main.usage' values
 - Revert WinResources changing of 'resource.wxl-file-name' value
 - Revert MsiInstallerStrings culture value changes
 - Apply JDK21 Open translation patch

Changes: https://git.openjdk.org/jdk/pull/14430/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14430&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309632
  Stats: 462 lines in 51 files changed: 279 ins; 48 del; 135 mod
  Patch: https://git.openjdk.org/jdk/pull/14430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14430/head:pull/14430

PR: https://git.openjdk.org/jdk/pull/14430

From jlu at openjdk.org  Mon Jun 12 22:16:50 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 22:16:50 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
Message-ID: <sLPcMLisa0Fflyr2kNxtrP3t6X2r7TFh7K59biOLnuw=.cb69b335-cac4-4565-9587-93d4abfae7ed@github.com>

On Mon, 12 Jun 2023 22:00:01 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

@naotoj @wangweij @sormuras could you please review the changes that affect the languages you are familiar with when you have the chance. Please use the HTML files for this, as they will be in UTF-8 native and not unicode escaped sequences.

@prrace @jonathan-gibbons @pavelrappo @lahodaj @wangweij @igraves @AlanBateman @eirbjo could you please review the modules / changes you are familiar with, thank you.

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

PR Comment: https://git.openjdk.org/jdk/pull/14430#issuecomment-1588180092

From duke at openjdk.org  Mon Jun 12 22:20:53 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Mon, 12 Jun 2023 22:20:53 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
Message-ID: <szKYrrvVQwYJ6F-ncMrYYHx_jOpaWhF8LUnsFCsl8Oo=.9d1f1585-c815-4c85-9f59-40ff5b08c8a0@github.com>

On Mon, 12 Jun 2023 22:00:01 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_de.properties line 115:

> 113: main.help.opt.main.validate=\      --validate             Validiert den Inhalt des JAR-Archivs. Diese Option\n                             validiert, dass die von einem Multi-Release-JAR-Archiv\n                             exportierte API \u00FCber die verschiedenen Releaseversionen\n                             hinweg konsistent ist.
> 114: main.help.opt.any=\ In jedem Modus g\u00FCltige Vorgangsmodifikatoren:\n\n  -C DIR                     Zum angegebenen Verzeichnis wechseln und die folgende\n                             Datei aufnehmen
> 115: main.help.opt.any.file=\  -f, --file=FILE            Der Name der Archivdatei. Wenn Sie dies lauslassen, wird entweder stdin oder\n                             stdout verwendet, je nach Vorgang\n      --release VERSION      Speichert alle der folgenden Dateien in einem versionierten Verzeichnis\n                             der JAR-Datei (d.h. META-INF/versions/VERSION/)

This change looks suspicious to me. The English word used is ?omitted?. ?Auslassen? is to ?Leave out?, while ?lauslassen? is to ?let go?. A native German speaker should confirm, I have only high school level German..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1227296089

From sspitsyn at openjdk.org  Mon Jun 12 22:27:42 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 12 Jun 2023 22:27:42 GMT
Subject: RFR: 8309878: Reduce inclusion of resolvedIndyEntry.hpp
In-Reply-To: <ngayct8s671hMXh-nM2Geo7wUpvGqDOzu4gvZr97Mzg=.b6a417c2-13f4-48e1-abef-743ac4966e6d@github.com>
References: <ngayct8s671hMXh-nM2Geo7wUpvGqDOzu4gvZr97Mzg=.b6a417c2-13f4-48e1-abef-743ac4966e6d@github.com>
Message-ID: <taQIbPhd950L1P5fndoELzvpKdKegJ6rJrwprn6DqWs=.f8da1da8-4fec-472d-9669-cd177377fdb8@github.com>

On Mon, 12 Jun 2023 19:52:36 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> resolvedIndyEntry.hpp was added in [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995) and is included in the popular cpCache.hpp. As a result, resolvedIndyEntry.hpp is included in 807 out of about 1160 hotspot .o files.
> 
> The contents of resolvedIndyEntry.hpp is infrequently used. Its inclusion should be moved from cpCache.hpp to cpCache.inline.hpp. This improves hotspot build time.
> 
> After this PR, resolvedIndyEntry.hpp is included in only 30 hotspot .o files.

Looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14427#pullrequestreview-1475909850

From jlu at openjdk.org  Mon Jun 12 22:32:14 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 22:32:14 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
Message-ID: <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Revert 'main.help.opt.any.file' value for _de

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14430/files
  - new: https://git.openjdk.org/jdk/pull/14430/files/ee072231..8ee7bf88

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14430&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14430&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14430/head:pull/14430

PR: https://git.openjdk.org/jdk/pull/14430

From jlu at openjdk.org  Mon Jun 12 22:32:34 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 Jun 2023 22:32:34 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <szKYrrvVQwYJ6F-ncMrYYHx_jOpaWhF8LUnsFCsl8Oo=.9d1f1585-c815-4c85-9f59-40ff5b08c8a0@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <szKYrrvVQwYJ6F-ncMrYYHx_jOpaWhF8LUnsFCsl8Oo=.9d1f1585-c815-4c85-9f59-40ff5b08c8a0@github.com>
Message-ID: <QG0atcb6MH7fn3CaUG7kFAU8Z-0dx0lvt8vPPzz6fD4=.750f4a45-f895-49f6-becd-7d9e6c994207@github.com>

On Mon, 12 Jun 2023 22:17:25 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert 'main.help.opt.any.file' value for _de
>
> src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_de.properties line 115:
> 
>> 113: main.help.opt.main.validate=\      --validate             Validiert den Inhalt des JAR-Archivs. Diese Option\n                             validiert, dass die von einem Multi-Release-JAR-Archiv\n                             exportierte API \u00FCber die verschiedenen Releaseversionen\n                             hinweg konsistent ist.
>> 114: main.help.opt.any=\ In jedem Modus g\u00FCltige Vorgangsmodifikatoren:\n\n  -C DIR                     Zum angegebenen Verzeichnis wechseln und die folgende\n                             Datei aufnehmen
>> 115: main.help.opt.any.file=\  -f, --file=FILE            Der Name der Archivdatei. Wenn Sie dies lauslassen, wird entweder stdin oder\n                             stdout verwendet, je nach Vorgang\n      --release VERSION      Speichert alle der folgenden Dateien in einem versionierten Verzeichnis\n                             der JAR-Datei (d.h. META-INF/versions/VERSION/)
> 
> This change looks suspicious to me. The English word used is ?omitted?. ?Auslassen? is to ?Leave out?, while ?lauslassen? is to ?let go?. A native German speaker should confirm, I have only high school level German..

Thanks for catching that. The translation tool incorrectly translated this, and we had manually fixed it with `Auslassen` in the last translation drop. This was an instance of the tool simply overwriting it this time. Will file a bug against the translation tool regarding this, to prevent it in future translation drops.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1227305807

From sspitsyn at openjdk.org  Mon Jun 12 22:34:50 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 12 Jun 2023 22:34:50 GMT
Subject: RFR: 8309757: com/sun/jdi/ReferrersTest.java fails with virtual
 test thread factory
In-Reply-To: <XJFnWkbx07iP9gyqD9g7g9xbIljRWAPoAYQW8aoDopg=.7f9e59c5-a11c-43a1-ab5d-f5cad0956f89@github.com>
References: <XJFnWkbx07iP9gyqD9g7g9xbIljRWAPoAYQW8aoDopg=.7f9e59c5-a11c-43a1-ab5d-f5cad0956f89@github.com>
Message-ID: <51cH2Cvc9gqoLYcEu3kOQVuea2NquATWxdbBl1TZl4A=.2888b97f-24c6-49b3-b405-5c3a9871066b@github.com>

On Fri, 9 Jun 2023 23:58:39 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This test launches a debuggee, which creates 11 instances of its main class, stores them in a static array of the main class, and then the debugger side iterates over all referrers to the main class instaces. Usually this is a pretty quick process and doesn't produce much in the way of output while walking the reference tree of referrers. However, with virtual threads the tree walking and output get unwieldy, and eventually it fails with:
> 
> 
> IOException reading output of child java interpreter:Stream closed
> java.lang.IllegalThreadStateException
> at jdk.jdi/com.sun.tools.jdi.JDWPException.toJDIException(JDWPException.java:76)
> at jdk.jdi/com.sun.tools.jdi.ThreadReferenceImpl.name(ThreadReferenceImpl.java:197)
> at jdk.jdi/com.sun.tools.jdi.ThreadReferenceImpl.toString(ThreadReferenceImpl.java:637)
> at java.base/java.lang.String.valueOf(String.java:4461)
> at ReferrersTest.showReferrers(ReferrersTest.java:438)
> at ReferrersTest.showReferrers(ReferrersTest.java:466)
> 
> 
> And ReferrersTest.showReferrers() has recursed about 200 levels deep. I'm not sure the order of these errors can be relied on. It looks like while walking the referrers tree, the test eventually stumbled upon a thread that had exited (but its Thread object was still alive), and this resulted in the test aborting. If I catch these exceptions, eventually the test times out while still working on referrers.
> 
> Judging by some of the output, it appears that introducing the TestScaffold class as a referrer to the main debuggee class is the root cause of all these extra referrers.
> 
> The test has a provision to cut off the recursion:
> 
> 
>         // We have to stop going up a referrer chain in some cases
>         Type rt = objRef.type();
>         if (rt instanceof ClassType) {
>             ClassType ct = (ClassType)rt;
>             String name = ct.name();
>             if (name.equals("sun.awt.SoftCache$ValueCell")) {
>                 return;
>             }
>             if (name.equals("java.lang.ref.Finalizer")) {
>                 return;
>             }
>             if (name.equals("java.lang.ref.SoftReference")) {
>                 return;
>             }
>             // oh oh, should really check for a subclass of ClassLoader :-)
>             if (name.indexOf("ClassLoader") >= 0) {
>                 return;
>             }
>             // No doubt there are other reasons to stop ...
>         }
> 
> 
> Adding TestScaffold to the list makes it so the referrer tree walking output is almost identical to what it is when not using virtual threads. ...

Looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14405#pullrequestreview-1475915772

From dholmes at openjdk.org  Tue Jun 13 02:22:40 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 13 Jun 2023 02:22:40 GMT
Subject: RFR: 8309468: Remove jvmti Allocate locker test case
In-Reply-To: <PhsM_U59XKD1frqZfAbpoVfHNR73L37ZQBe84D3Q0vg=.4db54bcb-b1b9-43bf-b9bd-e646868f82dd@github.com>
References: <PhsM_U59XKD1frqZfAbpoVfHNR73L37ZQBe84D3Q0vg=.4db54bcb-b1b9-43bf-b9bd-e646868f82dd@github.com>
Message-ID: <aNVH139YjmEtXW7Bftuaet1u67y7RKXZtmNFfygV6f0=.5869c1bb-935e-4365-8c30-52c45ffb4eaf@github.com>

On Mon, 12 Jun 2023 16:39:12 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> There is a bunch of tests that are used to test critical section/gc locker. One of the test is named jvmti locker. In that test, JNI code is doing a loop of ` jvmti->Allocate()` followed `sleep()` followed by a `jvmti->Deallocate()`. There is no JVM lock implementation to be tested on jvmti Allocate/Deallocate, they are implemented using malloc/free. Let us save test time, code complexity and confusion by removing this test. 
> 
> This removal is very similar to https://bugs.openjdk.org/browse/JDK-8309048
> 
> (Oracle) hs-tier5 testing passed on x86-64.

Serviceability folk should probably look at this and @lmesnik.

I can't see what this is actually trying to test either, so removing it seems fine to me too.

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14421#pullrequestreview-1476125547

From lmesnik at openjdk.org  Tue Jun 13 04:16:40 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 13 Jun 2023 04:16:40 GMT
Subject: RFR: 8309468: Remove jvmti Allocate locker test case
In-Reply-To: <PhsM_U59XKD1frqZfAbpoVfHNR73L37ZQBe84D3Q0vg=.4db54bcb-b1b9-43bf-b9bd-e646868f82dd@github.com>
References: <PhsM_U59XKD1frqZfAbpoVfHNR73L37ZQBe84D3Q0vg=.4db54bcb-b1b9-43bf-b9bd-e646868f82dd@github.com>
Message-ID: <kcPnJSs1nFtzPe6duDjQ9yav2ZD4YEqm4ugkDZG3Y8E=.d703c394-02e0-4110-9434-fad396881693@github.com>

On Mon, 12 Jun 2023 16:39:12 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> There is a bunch of tests that are used to test critical section/gc locker. One of the test is named jvmti locker. In that test, JNI code is doing a loop of ` jvmti->Allocate()` followed `sleep()` followed by a `jvmti->Deallocate()`. There is no JVM lock implementation to be tested on jvmti Allocate/Deallocate, they are implemented using malloc/free. Let us save test time, code complexity and confusion by removing this test. 
> 
> This removal is very similar to https://bugs.openjdk.org/browse/JDK-8309048
> 
> (Oracle) hs-tier5 testing passed on x86-64.

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14421#pullrequestreview-1476207969

From sspitsyn at openjdk.org  Tue Jun 13 05:41:48 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 13 Jun 2023 05:41:48 GMT
Subject: RFR: 8309468: Remove jvmti Allocate locker test case
In-Reply-To: <PhsM_U59XKD1frqZfAbpoVfHNR73L37ZQBe84D3Q0vg=.4db54bcb-b1b9-43bf-b9bd-e646868f82dd@github.com>
References: <PhsM_U59XKD1frqZfAbpoVfHNR73L37ZQBe84D3Q0vg=.4db54bcb-b1b9-43bf-b9bd-e646868f82dd@github.com>
Message-ID: <gpeE7YALw_ACnsR8Z2NpCoNpGMRYFdZ8fwsI_VQ6b7A=.02c626da-0b29-4bf7-b09b-431b6308e486@github.com>

On Mon, 12 Jun 2023 16:39:12 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> There is a bunch of tests that are used to test critical section/gc locker. One of the test is named jvmti locker. In that test, JNI code is doing a loop of ` jvmti->Allocate()` followed `sleep()` followed by a `jvmti->Deallocate()`. There is no JVM lock implementation to be tested on jvmti Allocate/Deallocate, they are implemented using malloc/free. Let us save test time, code complexity and confusion by removing this test. 
> 
> This removal is very similar to https://bugs.openjdk.org/browse/JDK-8309048
> 
> (Oracle) hs-tier5 testing passed on x86-64.

I also do not see any value in this test, so it looks good to get rid of it.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14421#pullrequestreview-1476285877

From mdoerr at openjdk.org  Tue Jun 13 08:30:58 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 13 Jun 2023 08:30:58 GMT
Subject: Integrated: 8309462: [AIX]
 vmTestbase/nsk/jvmti/RunAgentThread/agentthr001/TestDescription.java crashing
 due to empty while loop
In-Reply-To: <wt_i-ZtqoIxyQ8bxwIFMlz4BXsk-LcK2S67NTC0IVAI=.8de72b67-94b7-44da-97e5-eca5822bfada@github.com>
References: <wt_i-ZtqoIxyQ8bxwIFMlz4BXsk-LcK2S67NTC0IVAI=.8de72b67-94b7-44da-97e5-eca5822bfada@github.com>
Message-ID: <FU1zb58xackMgB3KGSYjmh56a3JUsinJ6urpMOw0j-Q=.58a53f85-905c-44e1-9ddd-ba864c1a0632@github.com>

On Mon, 12 Jun 2023 14:36:56 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Test fix for test failing on AIX because of undefined behavior in current implementation.

This pull request has now been integrated.

Changeset: 08eff92b
Author:    Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/08eff92b5e1e42cf299c1da8d5fa88d92b840505
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8309462: [AIX] vmTestbase/nsk/jvmti/RunAgentThread/agentthr001/TestDescription.java crashing due to empty while loop

Reviewed-by: mbaesken
Backport-of: cf9e6353cc6fe9e57a7a9883813d09892e7e7621

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

PR: https://git.openjdk.org/jdk21/pull/9

From yzheng at openjdk.org  Tue Jun 13 08:34:49 2023
From: yzheng at openjdk.org (Yudi Zheng)
Date: Tue, 13 Jun 2023 08:34:49 GMT
Subject: RFR: 8309671: Avoid using jvmci.Compiler property to determine if
 Graal is enabled
In-Reply-To: <IawBz7ECRbEFc1GCsQzaP0-LR7HwlplLrLkuZOnn-fk=.ac148e99-c5c4-4571-abaa-6025458e63ce@github.com>
References: <IawBz7ECRbEFc1GCsQzaP0-LR7HwlplLrLkuZOnn-fk=.ac148e99-c5c4-4571-abaa-6025458e63ce@github.com>
Message-ID: <XkAXRxrjD_JzP180ATy2qgZT5ruxjdBx1jRj8YAYjF8=.b43e2bd6-ddbb-4e25-a84f-305244005dfd@github.com>

On Thu, 8 Jun 2023 17:14:39 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

> HeapMonitor checks if System.getProperty("jvmci.Compiler") is graal and will not enforce checking line number derived from uncommon trap debug info. However, Graal does not set this property explicitly.

Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/14381#issuecomment-1588815689

From yzheng at openjdk.org  Tue Jun 13 09:06:00 2023
From: yzheng at openjdk.org (Yudi Zheng)
Date: Tue, 13 Jun 2023 09:06:00 GMT
Subject: Integrated: 8309671: Avoid using jvmci.Compiler property to determine
 if Graal is enabled
In-Reply-To: <IawBz7ECRbEFc1GCsQzaP0-LR7HwlplLrLkuZOnn-fk=.ac148e99-c5c4-4571-abaa-6025458e63ce@github.com>
References: <IawBz7ECRbEFc1GCsQzaP0-LR7HwlplLrLkuZOnn-fk=.ac148e99-c5c4-4571-abaa-6025458e63ce@github.com>
Message-ID: <A2XaQ41ubtM1eeIb4nOgMI5lUM9befvhuas581hNvIY=.9854f3c2-720a-45e5-94f6-061b128be221@github.com>

On Thu, 8 Jun 2023 17:14:39 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

> HeapMonitor checks if System.getProperty("jvmci.Compiler") is graal and will not enforce checking line number derived from uncommon trap debug info. However, Graal does not set this property explicitly.

This pull request has now been integrated.

Changeset: 4f23fc1f
Author:    Yudi Zheng <yzheng at openjdk.org>
Committer: Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4f23fc1f273ea30f49c5412a2f25c07f8982d5b5
Stats:     3 lines in 2 files changed: 0 ins; 2 del; 1 mod

8309671: Avoid using jvmci.Compiler property to determine if Graal is enabled

Reviewed-by: dnsimon, sspitsyn

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

PR: https://git.openjdk.org/jdk/pull/14381

From kevinw at openjdk.org  Tue Jun 13 11:19:49 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 13 Jun 2023 11:19:49 GMT
Subject: RFR: 8309757: com/sun/jdi/ReferrersTest.java fails with virtual
 test thread factory
In-Reply-To: <XJFnWkbx07iP9gyqD9g7g9xbIljRWAPoAYQW8aoDopg=.7f9e59c5-a11c-43a1-ab5d-f5cad0956f89@github.com>
References: <XJFnWkbx07iP9gyqD9g7g9xbIljRWAPoAYQW8aoDopg=.7f9e59c5-a11c-43a1-ab5d-f5cad0956f89@github.com>
Message-ID: <w9TyF1mrxP9njw8sUDjX7hcWTQSkx3OJdL4ruD6MeFw=.de741eb9-4e77-4ddd-8a7c-b36cc55e9a88@github.com>

On Fri, 9 Jun 2023 23:58:39 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This test launches a debuggee, which creates 11 instances of its main class, stores them in a static array of the main class, and then the debugger side iterates over all referrers to the main class instaces. Usually this is a pretty quick process and doesn't produce much in the way of output while walking the reference tree of referrers. However, with virtual threads the tree walking and output get unwieldy, and eventually it fails with:
> 
> 
> IOException reading output of child java interpreter:Stream closed
> java.lang.IllegalThreadStateException
> at jdk.jdi/com.sun.tools.jdi.JDWPException.toJDIException(JDWPException.java:76)
> at jdk.jdi/com.sun.tools.jdi.ThreadReferenceImpl.name(ThreadReferenceImpl.java:197)
> at jdk.jdi/com.sun.tools.jdi.ThreadReferenceImpl.toString(ThreadReferenceImpl.java:637)
> at java.base/java.lang.String.valueOf(String.java:4461)
> at ReferrersTest.showReferrers(ReferrersTest.java:438)
> at ReferrersTest.showReferrers(ReferrersTest.java:466)
> 
> 
> And ReferrersTest.showReferrers() has recursed about 200 levels deep. I'm not sure the order of these errors can be relied on. It looks like while walking the referrers tree, the test eventually stumbled upon a thread that had exited (but its Thread object was still alive), and this resulted in the test aborting. If I catch these exceptions, eventually the test times out while still working on referrers.
> 
> Judging by some of the output, it appears that introducing the TestScaffold class as a referrer to the main debuggee class is the root cause of all these extra referrers.
> 
> The test has a provision to cut off the recursion:
> 
> 
>         // We have to stop going up a referrer chain in some cases
>         Type rt = objRef.type();
>         if (rt instanceof ClassType) {
>             ClassType ct = (ClassType)rt;
>             String name = ct.name();
>             if (name.equals("sun.awt.SoftCache$ValueCell")) {
>                 return;
>             }
>             if (name.equals("java.lang.ref.Finalizer")) {
>                 return;
>             }
>             if (name.equals("java.lang.ref.SoftReference")) {
>                 return;
>             }
>             // oh oh, should really check for a subclass of ClassLoader :-)
>             if (name.indexOf("ClassLoader") >= 0) {
>                 return;
>             }
>             // No doubt there are other reasons to stop ...
>         }
> 
> 
> Adding TestScaffold to the list makes it so the referrer tree walking output is almost identical to what it is when not using virtual threads. ...

Looks good.

This test test/jdk/com/sun/jdi/ReferrersTest.java, and also AnyDebuggeeTest.java and InstancesTest.java have comments referring to running them with "runregresS".  Maybe this is some old test harness or launcher that no longer exists, probably wants to be deleted or reworded, in a separate update.

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

Marked as reviewed by kevinw (Committer).

PR Review: https://git.openjdk.org/jdk/pull/14405#pullrequestreview-1476899872
PR Comment: https://git.openjdk.org/jdk/pull/14405#issuecomment-1589093501

From lkorinth at openjdk.org  Tue Jun 13 12:34:59 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 13 Jun 2023 12:34:59 GMT
Subject: RFR: 8309468: Remove jvmti Allocate locker test case
In-Reply-To: <PhsM_U59XKD1frqZfAbpoVfHNR73L37ZQBe84D3Q0vg=.4db54bcb-b1b9-43bf-b9bd-e646868f82dd@github.com>
References: <PhsM_U59XKD1frqZfAbpoVfHNR73L37ZQBe84D3Q0vg=.4db54bcb-b1b9-43bf-b9bd-e646868f82dd@github.com>
Message-ID: <jXDEXOyVA6wzBZ1Ks8I3ydAsXKiiRGfY6RT1YzGi9K0=.a12124e2-fac4-4fdb-9c1e-dd0064d8dc06@github.com>

On Mon, 12 Jun 2023 16:39:12 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> There is a bunch of tests that are used to test critical section/gc locker. One of the test is named jvmti locker. In that test, JNI code is doing a loop of ` jvmti->Allocate()` followed `sleep()` followed by a `jvmti->Deallocate()`. There is no JVM lock implementation to be tested on jvmti Allocate/Deallocate, they are implemented using malloc/free. Let us save test time, code complexity and confusion by removing this test. 
> 
> This removal is very similar to https://bugs.openjdk.org/browse/JDK-8309048
> 
> (Oracle) hs-tier5 testing passed on x86-64.

Thanks David, Leonid and Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/14421#issuecomment-1589211147

From lkorinth at openjdk.org  Tue Jun 13 12:35:00 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 13 Jun 2023 12:35:00 GMT
Subject: Integrated: 8309468: Remove jvmti Allocate locker test case
In-Reply-To: <PhsM_U59XKD1frqZfAbpoVfHNR73L37ZQBe84D3Q0vg=.4db54bcb-b1b9-43bf-b9bd-e646868f82dd@github.com>
References: <PhsM_U59XKD1frqZfAbpoVfHNR73L37ZQBe84D3Q0vg=.4db54bcb-b1b9-43bf-b9bd-e646868f82dd@github.com>
Message-ID: <dfUoCeqM0nQtD07PMQ-qZmNSjXRSHKVzOnzLAg4Rb68=.909767b0-5a20-4fad-b4b1-5f5a9a65d82c@github.com>

On Mon, 12 Jun 2023 16:39:12 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> There is a bunch of tests that are used to test critical section/gc locker. One of the test is named jvmti locker. In that test, JNI code is doing a loop of ` jvmti->Allocate()` followed `sleep()` followed by a `jvmti->Deallocate()`. There is no JVM lock implementation to be tested on jvmti Allocate/Deallocate, they are implemented using malloc/free. Let us save test time, code complexity and confusion by removing this test. 
> 
> This removal is very similar to https://bugs.openjdk.org/browse/JDK-8309048
> 
> (Oracle) hs-tier5 testing passed on x86-64.

This pull request has now been integrated.

Changeset: c884862a
Author:    Leo Korinth <lkorinth at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c884862ad2189654596df27a76ab685dcd7399f6
Stats:     260 lines in 9 files changed: 0 ins; 257 del; 3 mod

8309468: Remove jvmti Allocate locker test case

Reviewed-by: dholmes, lmesnik, sspitsyn

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

PR: https://git.openjdk.org/jdk/pull/14421

From matsaave at openjdk.org  Tue Jun 13 15:13:42 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 13 Jun 2023 15:13:42 GMT
Subject: RFR: 8309878: Reduce inclusion of resolvedIndyEntry.hpp
In-Reply-To: <ngayct8s671hMXh-nM2Geo7wUpvGqDOzu4gvZr97Mzg=.b6a417c2-13f4-48e1-abef-743ac4966e6d@github.com>
References: <ngayct8s671hMXh-nM2Geo7wUpvGqDOzu4gvZr97Mzg=.b6a417c2-13f4-48e1-abef-743ac4966e6d@github.com>
Message-ID: <30EVi0eDcl2WRGeDGLrlYWEckKuzAnwH2o9by8w3ihg=.1c26c41a-45f7-4065-b365-96fae46b3c51@github.com>

On Mon, 12 Jun 2023 19:52:36 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> resolvedIndyEntry.hpp was added in [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995) and is included in the popular cpCache.hpp. As a result, resolvedIndyEntry.hpp is included in 807 out of about 1160 hotspot .o files.
> 
> The contents of resolvedIndyEntry.hpp is infrequently used. Its inclusion should be moved from cpCache.hpp to cpCache.inline.hpp. This improves hotspot build time.
> 
> After this PR, resolvedIndyEntry.hpp is included in only 30 hotspot .o files.

Looks good, thanks for this!

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

Marked as reviewed by matsaave (Committer).

PR Review: https://git.openjdk.org/jdk/pull/14427#pullrequestreview-1477437064

From cjplummer at openjdk.org  Tue Jun 13 18:07:04 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 13 Jun 2023 18:07:04 GMT
Subject: RFR: 8309757: com/sun/jdi/ReferrersTest.java fails with virtual
 test thread factory [v2]
In-Reply-To: <XJFnWkbx07iP9gyqD9g7g9xbIljRWAPoAYQW8aoDopg=.7f9e59c5-a11c-43a1-ab5d-f5cad0956f89@github.com>
References: <XJFnWkbx07iP9gyqD9g7g9xbIljRWAPoAYQW8aoDopg=.7f9e59c5-a11c-43a1-ab5d-f5cad0956f89@github.com>
Message-ID: <_hpiQEe-SzfV7Kp1W2KGaHC4AJI632gD8hkpMOtDjzw=.2eab8b3f-4288-47d8-8acf-c99a509dc136@github.com>

> This test launches a debuggee, which creates 11 instances of its main class, stores them in a static array of the main class, and then the debugger side iterates over all referrers to the main class instaces. Usually this is a pretty quick process and doesn't produce much in the way of output while walking the reference tree of referrers. However, with virtual threads the tree walking and output get unwieldy, and eventually it fails with:
> 
> 
> IOException reading output of child java interpreter:Stream closed
> java.lang.IllegalThreadStateException
> at jdk.jdi/com.sun.tools.jdi.JDWPException.toJDIException(JDWPException.java:76)
> at jdk.jdi/com.sun.tools.jdi.ThreadReferenceImpl.name(ThreadReferenceImpl.java:197)
> at jdk.jdi/com.sun.tools.jdi.ThreadReferenceImpl.toString(ThreadReferenceImpl.java:637)
> at java.base/java.lang.String.valueOf(String.java:4461)
> at ReferrersTest.showReferrers(ReferrersTest.java:438)
> at ReferrersTest.showReferrers(ReferrersTest.java:466)
> 
> 
> And ReferrersTest.showReferrers() has recursed about 200 levels deep. I'm not sure the order of these errors can be relied on. It looks like while walking the referrers tree, the test eventually stumbled upon a thread that had exited (but its Thread object was still alive), and this resulted in the test aborting. If I catch these exceptions, eventually the test times out while still working on referrers.
> 
> Judging by some of the output, it appears that introducing the TestScaffold class as a referrer to the main debuggee class is the root cause of all these extra referrers.
> 
> The test has a provision to cut off the recursion:
> 
> 
>         // We have to stop going up a referrer chain in some cases
>         Type rt = objRef.type();
>         if (rt instanceof ClassType) {
>             ClassType ct = (ClassType)rt;
>             String name = ct.name();
>             if (name.equals("sun.awt.SoftCache$ValueCell")) {
>                 return;
>             }
>             if (name.equals("java.lang.ref.Finalizer")) {
>                 return;
>             }
>             if (name.equals("java.lang.ref.SoftReference")) {
>                 return;
>             }
>             // oh oh, should really check for a subclass of ClassLoader :-)
>             if (name.indexOf("ClassLoader") >= 0) {
>                 return;
>             }
>             // No doubt there are other reasons to stop ...
>         }
> 
> 
> Adding TestScaffold to the list makes it so the referrer tree walking output is almost identical to what it is when not using virtual threads. ...

Chris Plummer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge
 - Do some additional pruning needed when run with a virtual thread

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

Changes: https://git.openjdk.org/jdk/pull/14405/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14405&range=01
  Stats: 5 lines in 2 files changed: 3 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14405.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14405/head:pull/14405

PR: https://git.openjdk.org/jdk/pull/14405

From cjplummer at openjdk.org  Tue Jun 13 18:10:59 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 13 Jun 2023 18:10:59 GMT
Subject: RFR: 8309757: com/sun/jdi/ReferrersTest.java fails with virtual
 test thread factory
In-Reply-To: <XJFnWkbx07iP9gyqD9g7g9xbIljRWAPoAYQW8aoDopg=.7f9e59c5-a11c-43a1-ab5d-f5cad0956f89@github.com>
References: <XJFnWkbx07iP9gyqD9g7g9xbIljRWAPoAYQW8aoDopg=.7f9e59c5-a11c-43a1-ab5d-f5cad0956f89@github.com>
Message-ID: <69LTJQywkD14tGUrwKrBvlgdmA7Q064RIJsl8aQ0AXM=.33ec5f6c-403d-4135-b877-915d24e45974@github.com>

On Fri, 9 Jun 2023 23:58:39 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This test launches a debuggee, which creates 11 instances of its main class, stores them in a static array of the main class, and then the debugger side iterates over all referrers to the main class instaces. Usually this is a pretty quick process and doesn't produce much in the way of output while walking the reference tree of referrers. However, with virtual threads the tree walking and output get unwieldy, and eventually it fails with:
> 
> 
> IOException reading output of child java interpreter:Stream closed
> java.lang.IllegalThreadStateException
> at jdk.jdi/com.sun.tools.jdi.JDWPException.toJDIException(JDWPException.java:76)
> at jdk.jdi/com.sun.tools.jdi.ThreadReferenceImpl.name(ThreadReferenceImpl.java:197)
> at jdk.jdi/com.sun.tools.jdi.ThreadReferenceImpl.toString(ThreadReferenceImpl.java:637)
> at java.base/java.lang.String.valueOf(String.java:4461)
> at ReferrersTest.showReferrers(ReferrersTest.java:438)
> at ReferrersTest.showReferrers(ReferrersTest.java:466)
> 
> 
> And ReferrersTest.showReferrers() has recursed about 200 levels deep. I'm not sure the order of these errors can be relied on. It looks like while walking the referrers tree, the test eventually stumbled upon a thread that had exited (but its Thread object was still alive), and this resulted in the test aborting. If I catch these exceptions, eventually the test times out while still working on referrers.
> 
> Judging by some of the output, it appears that introducing the TestScaffold class as a referrer to the main debuggee class is the root cause of all these extra referrers.
> 
> The test has a provision to cut off the recursion:
> 
> 
>         // We have to stop going up a referrer chain in some cases
>         Type rt = objRef.type();
>         if (rt instanceof ClassType) {
>             ClassType ct = (ClassType)rt;
>             String name = ct.name();
>             if (name.equals("sun.awt.SoftCache$ValueCell")) {
>                 return;
>             }
>             if (name.equals("java.lang.ref.Finalizer")) {
>                 return;
>             }
>             if (name.equals("java.lang.ref.SoftReference")) {
>                 return;
>             }
>             // oh oh, should really check for a subclass of ClassLoader :-)
>             if (name.indexOf("ClassLoader") >= 0) {
>                 return;
>             }
>             // No doubt there are other reasons to stop ...
>         }
> 
> 
> Adding TestScaffold to the list makes it so the referrer tree walking output is almost identical to what it is when not using virtual threads. ...

Thanks for the reviews Serguei and Kevin

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

PR Comment: https://git.openjdk.org/jdk/pull/14405#issuecomment-1589795544

From cjplummer at openjdk.org  Tue Jun 13 18:11:00 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 13 Jun 2023 18:11:00 GMT
Subject: Integrated: 8309757: com/sun/jdi/ReferrersTest.java fails with virtual
 test thread factory
In-Reply-To: <XJFnWkbx07iP9gyqD9g7g9xbIljRWAPoAYQW8aoDopg=.7f9e59c5-a11c-43a1-ab5d-f5cad0956f89@github.com>
References: <XJFnWkbx07iP9gyqD9g7g9xbIljRWAPoAYQW8aoDopg=.7f9e59c5-a11c-43a1-ab5d-f5cad0956f89@github.com>
Message-ID: <7Jsm60VigvH37nrIKYaByOB9C3xuuCoKPeMV1xAsxyU=.590453b6-b9c7-4661-a380-92395ddc7903@github.com>

On Fri, 9 Jun 2023 23:58:39 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This test launches a debuggee, which creates 11 instances of its main class, stores them in a static array of the main class, and then the debugger side iterates over all referrers to the main class instaces. Usually this is a pretty quick process and doesn't produce much in the way of output while walking the reference tree of referrers. However, with virtual threads the tree walking and output get unwieldy, and eventually it fails with:
> 
> 
> IOException reading output of child java interpreter:Stream closed
> java.lang.IllegalThreadStateException
> at jdk.jdi/com.sun.tools.jdi.JDWPException.toJDIException(JDWPException.java:76)
> at jdk.jdi/com.sun.tools.jdi.ThreadReferenceImpl.name(ThreadReferenceImpl.java:197)
> at jdk.jdi/com.sun.tools.jdi.ThreadReferenceImpl.toString(ThreadReferenceImpl.java:637)
> at java.base/java.lang.String.valueOf(String.java:4461)
> at ReferrersTest.showReferrers(ReferrersTest.java:438)
> at ReferrersTest.showReferrers(ReferrersTest.java:466)
> 
> 
> And ReferrersTest.showReferrers() has recursed about 200 levels deep. I'm not sure the order of these errors can be relied on. It looks like while walking the referrers tree, the test eventually stumbled upon a thread that had exited (but its Thread object was still alive), and this resulted in the test aborting. If I catch these exceptions, eventually the test times out while still working on referrers.
> 
> Judging by some of the output, it appears that introducing the TestScaffold class as a referrer to the main debuggee class is the root cause of all these extra referrers.
> 
> The test has a provision to cut off the recursion:
> 
> 
>         // We have to stop going up a referrer chain in some cases
>         Type rt = objRef.type();
>         if (rt instanceof ClassType) {
>             ClassType ct = (ClassType)rt;
>             String name = ct.name();
>             if (name.equals("sun.awt.SoftCache$ValueCell")) {
>                 return;
>             }
>             if (name.equals("java.lang.ref.Finalizer")) {
>                 return;
>             }
>             if (name.equals("java.lang.ref.SoftReference")) {
>                 return;
>             }
>             // oh oh, should really check for a subclass of ClassLoader :-)
>             if (name.indexOf("ClassLoader") >= 0) {
>                 return;
>             }
>             // No doubt there are other reasons to stop ...
>         }
> 
> 
> Adding TestScaffold to the list makes it so the referrer tree walking output is almost identical to what it is when not using virtual threads. ...

This pull request has now been integrated.

Changeset: d7251c17
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d7251c1755779f8c4fdeac16ccb797ed45b1dfd4
Stats:     5 lines in 2 files changed: 3 ins; 1 del; 1 mod

8309757: com/sun/jdi/ReferrersTest.java fails with virtual test thread factory

Reviewed-by: sspitsyn, kevinw

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

PR: https://git.openjdk.org/jdk/pull/14405

From naoto at openjdk.org  Tue Jun 13 18:41:52 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 13 Jun 2023 18:41:52 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
Message-ID: <LQj9A4_3dfSUIozPcVuYCUF1QhseODhxAft9eKH33E4=.30cf5fee-d616-4726-8c33-1b22bfb29c26@github.com>

On Mon, 12 Jun 2023 22:32:14 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
>> 
>> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
>> 
>> For example,
>> 
>> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
>> 
>> 
>> Please note that the HTML files only apply to .properties, and not .java resources.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert 'main.help.opt.any.file' value for _de

Left some comments on the translations mainly in Japanese. It is now very easy to look at the l10n changes in the generated HTML. One small comment to the tool is that it would be nice if the order in HTML (alphabetically sorted currently) aligns with the order in the actual resource file. It is a great improvement anyways.

src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_ja.properties line 63:

> 61: FileChooser.newFolderExistsError.textAndMnemonic=\u305D\u306E\u540D\u524D\u306F\u3059\u3067\u306B\u4F7F\u7528\u3055\u308C\u3066\u3044\u307E\u3059
> 62: FileChooser.chooseButton.textAndMnemonic=\u9078\u629E
> 63: FileChooser.chooseButtonToolTip.textAndMnemonic=\u9078\u629E\u3057\u305F\u30D5\u30A1\u30A4\u30EB\u3092\u8FFD\u52A0\u3057\u307E\u3059

The translation seems wrong. It means to *add* the selected file, which is not the same meaning as in English file

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties line 140:

> 138: 
> 139: # 0: type, 1: name
> 140: compiler.err.annotation.unrecognized.attribute.name=Annotation @{0} weist das unbekannte Attribut "{1}" auf

Is it intentional to replace single quotes with double quotes? It is done in several locations in this file, but other languages keep using single quotes as in the source English resource file.

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 505:

> 503: 
> 504: compiler.warn.possible.this.escape.location=\u4E8B\u524D\u306B\u6307\u5B9A\u53EF\u80FD\u306A''this''\u30A8\u30B9\u30B1\u30FC\u30D7\u306F\u547C\u51FA\u3057\u3092\u4ECB\u3057\u3066\u3053\u3053\u306B\u51FA\u73FE\u3057\u307E\u3059
> 505: 

These translations are very cryptic. Cannot understand it at first hand.

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 959:

> 957: 
> 958: compiler.err.text.block.template.is.not.well.formed=\u30C6\u30AD\u30B9\u30C8\u30FB\u30D6\u30ED\u30C3\u30AF\u30FB\u30C6\u30F3\u30D7\u30EC\u30FC\u30C8\u304C\u6574\u5F62\u5F0F\u3067\u306F\u3042\u308A\u307E\u305B\u3093
> 959: 

The translation of "well-formed" is incorrect. It is not ???

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

PR Review: https://git.openjdk.org/jdk/pull/14430#pullrequestreview-1477795175
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228530280
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228521409
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228538758
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228529769

From jlu at openjdk.org  Tue Jun 13 18:56:44 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 13 Jun 2023 18:56:44 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <LQj9A4_3dfSUIozPcVuYCUF1QhseODhxAft9eKH33E4=.30cf5fee-d616-4726-8c33-1b22bfb29c26@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
 <LQj9A4_3dfSUIozPcVuYCUF1QhseODhxAft9eKH33E4=.30cf5fee-d616-4726-8c33-1b22bfb29c26@github.com>
Message-ID: <05VweeA-JZy6fvHzscLEDLi4nPZM0xhDiaOqYcceMgI=.2574b0d1-92ea-4319-9c45-dbd9df91ad4f@github.com>

On Tue, 13 Jun 2023 18:13:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert 'main.help.opt.any.file' value for _de
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties line 140:
> 
>> 138: 
>> 139: # 0: type, 1: name
>> 140: compiler.err.annotation.unrecognized.attribute.name=Annotation @{0} weist das unbekannte Attribut "{1}" auf
> 
> Is it intentional to replace single quotes with double quotes? It is done in several locations in this file, but other languages keep using single quotes as in the source English resource file.

I will consult the language specialist on this. I remember in previous discussions that certain languages would format punctuation differently, but let ask about this specific instance.

> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 959:
> 
>> 957: 
>> 958: compiler.err.text.block.template.is.not.well.formed=\u30C6\u30AD\u30B9\u30C8\u30FB\u30D6\u30ED\u30C3\u30AF\u30FB\u30C6\u30F3\u30D7\u30EC\u30FC\u30C8\u304C\u6574\u5F62\u5F0F\u3067\u306F\u3042\u308A\u307E\u305B\u3093
>> 959: 
> 
> The translation of "well-formed" is incorrect. It is not ???

For translations that are incorrect, I can file a bug against the tool. Such a fix would probably not happen soon, can you suggest an alternative for now?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228567669
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228570665

From naoto at openjdk.org  Tue Jun 13 20:24:46 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 13 Jun 2023 20:24:46 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
Message-ID: <OvLbgWiuc9DJFe_5qhLWQ0IgRJWDV7ujJL4xCmt2yz0=.e05274e1-01e5-4aa8-a892-7335e16057da@github.com>

On Mon, 12 Jun 2023 22:32:14 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
>> 
>> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
>> 
>> For example,
>> 
>> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
>> 
>> 
>> Please note that the HTML files only apply to .properties, and not .java resources.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert 'main.help.opt.any.file' value for _de

Left some suggestions. Should be looked at by translators later.

src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_ja.properties line 63:

> 61: FileChooser.newFolderExistsError.textAndMnemonic=\u305D\u306E\u540D\u524D\u306F\u3059\u3067\u306B\u4F7F\u7528\u3055\u308C\u3066\u3044\u307E\u3059
> 62: FileChooser.chooseButton.textAndMnemonic=\u9078\u629E
> 63: FileChooser.chooseButtonToolTip.textAndMnemonic=\u9078\u629E\u3057\u305F\u30D5\u30A1\u30A4\u30EB\u3092\u8FFD\u52A0\u3057\u307E\u3059

Suggestion:

FileChooser.chooseButtonToolTip.textAndMnemonic=\u9078\u629e\u3055\u308c\u3066\u3044\u308b\u30d5\u30a1\u30a4\u30eb\u3092\u9078\u629e\u3057\u307e\u3059

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 502:

> 500: compiler.warn.forward.ref=\u521D\u671F\u5316\u3055\u308C\u308B\u524D\u306E\u5909\u6570''{0}''\u3092\u53C2\u7167\u3057\u3088\u3046\u3068\u3057\u307E\u3057\u305F
> 501: 
> 502: compiler.warn.possible.this.escape=\u30B5\u30D6\u30AF\u30E9\u30B9\u524D\u306B\u6307\u5B9A\u53EF\u80FD\u306A''this''\u30A8\u30B9\u30B1\u30FC\u30D7\u306F\u5B8C\u5168\u306B\u521D\u671F\u5316\u3055\u308C\u307E\u3059

Suggestion:

compiler.warn.possible.this.escape=\u30b5\u30d6\u30af\u30e9\u30b9\u304c\u521d\u671f\u5316\u3055\u308c\u308b\u524d\u306e''this''\u30a8\u30b9\u30b1\u30fc\u30d7\u306e\u53ef\u80fd\u6027\u304c\u3042\u308a\u307e\u3059

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 504:

> 502: compiler.warn.possible.this.escape=\u30B5\u30D6\u30AF\u30E9\u30B9\u524D\u306B\u6307\u5B9A\u53EF\u80FD\u306A''this''\u30A8\u30B9\u30B1\u30FC\u30D7\u306F\u5B8C\u5168\u306B\u521D\u671F\u5316\u3055\u308C\u307E\u3059
> 503: 
> 504: compiler.warn.possible.this.escape.location=\u4E8B\u524D\u306B\u6307\u5B9A\u53EF\u80FD\u306A''this''\u30A8\u30B9\u30B1\u30FC\u30D7\u306F\u547C\u51FA\u3057\u3092\u4ECB\u3057\u3066\u3053\u3053\u306B\u51FA\u73FE\u3057\u307E\u3059

Suggestion:

compiler.warn.possible.this.escape.location=\u4e8b\u524d\u306e''this''\u30a8\u30b9\u30b1\u30fc\u30d7\u306f\u3053\u306e\u547c\u3073\u51fa\u3057\u3067\u51fa\u73fe\u3057\u307e\u3059

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 956:

> 954: compiler.err.unclosed.text.block=\u9589\u3058\u3089\u308C\u3066\u3044\u306A\u3044\u30C6\u30AD\u30B9\u30C8\u30FB\u30D6\u30ED\u30C3\u30AF
> 955: 
> 956: compiler.err.string.template.is.not.well.formed=\u6587\u5B57\u5217\u30C6\u30F3\u30D7\u30EC\u30FC\u30C8\u304C\u6574\u5F62\u5F0F\u3067\u306F\u3042\u308A\u307E\u305B\u3093

Suggestion:

compiler.err.string.template.is.not.well.formed=\u6587\u5b57\u5217\u30c6\u30f3\u30d7\u30ec\u30fc\u30c8\u304c\u9069\u683c\u3067\u306f\u3042\u308a\u307e\u305b\u3093

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties line 958:

> 956: compiler.err.string.template.is.not.well.formed=\u6587\u5B57\u5217\u30C6\u30F3\u30D7\u30EC\u30FC\u30C8\u304C\u6574\u5F62\u5F0F\u3067\u306F\u3042\u308A\u307E\u305B\u3093
> 957: 
> 958: compiler.err.text.block.template.is.not.well.formed=\u30C6\u30AD\u30B9\u30C8\u30FB\u30D6\u30ED\u30C3\u30AF\u30FB\u30C6\u30F3\u30D7\u30EC\u30FC\u30C8\u304C\u6574\u5F62\u5F0F\u3067\u306F\u3042\u308A\u307E\u305B\u3093

Suggestion:

compiler.err.text.block.template.is.not.well.formed=\u30c6\u30ad\u30b9\u30c8\u30fb\u30d6\u30ed\u30c3\u30af\u30fb\u30c6\u30f3\u30d7\u30ec\u30fc\u30c8\u304c\u9069\u683c\u3067\u306f\u3042\u308a\u307e\u305b\u3093

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

Changes requested by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14430#pullrequestreview-1477963618
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228635514
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228648714
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228651272
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228653057
PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228654384

From weijun at openjdk.org  Tue Jun 13 20:58:51 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 13 Jun 2023 20:58:51 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
Message-ID: <YquJjfQ3DWo1mXUU9YXkfP0iYYnuuw11K4n-UmhEP9U=.fa39bf55-2813-422e-a84c-587f0ca40654@github.com>

On Mon, 12 Jun 2023 22:32:14 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
>> 
>> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
>> 
>> For example,
>> 
>> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
>> 
>> 
>> Please note that the HTML files only apply to .properties, and not .java resources.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert 'main.help.opt.any.file' value for _de

Some comments:

- `src/java.base/share/classes/sun/launcher/resources/launcher`

`? private`. "private" should be translated, just like the "static" in the 2nd box.

- `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler`

`compiler.err.annotation.unrecognized.attribute.name`: Here "annotation" is translated to "??"? How do you translate "comment"?

`compiler.err.enum.label.must.be.enum.constant`: "constant" should be translated.

`compiler.warn.possible.this.escape`, `compiler.warn.possible.this.escape.location`: "escape" might not mean "??". It's more like its original meaning "run away" or "referenced".


- `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac`:

`javac.opt.Xlint.desc.output-file-clash`: "native header files" is translated into "??????". The "??" is strange, I'd rather just say "???" as there is no non-native header file.

- `src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap`

I don't think the new translation is better than the old one.

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

PR Comment: https://git.openjdk.org/jdk/pull/14430#issuecomment-1590013825

From jlu at openjdk.org  Tue Jun 13 21:06:25 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 13 Jun 2023 21:06:25 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v3]
In-Reply-To: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
Message-ID: <geYM5H0XN5NNvVmRzx5TxgqMaD17xbb7-DCnO_oFVbw=.d00caade-f19d-466e-a71d-7f7cbba183cc@github.com>

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Review: use Naoto's recommended ja values

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14430/files
  - new: https://git.openjdk.org/jdk/pull/14430/files/8ee7bf88..7801eefb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14430&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14430&range=01-02

  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14430/head:pull/14430

PR: https://git.openjdk.org/jdk/pull/14430

From jlu at openjdk.org  Tue Jun 13 21:06:28 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 13 Jun 2023 21:06:28 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <OvLbgWiuc9DJFe_5qhLWQ0IgRJWDV7ujJL4xCmt2yz0=.e05274e1-01e5-4aa8-a892-7335e16057da@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
 <OvLbgWiuc9DJFe_5qhLWQ0IgRJWDV7ujJL4xCmt2yz0=.e05274e1-01e5-4aa8-a892-7335e16057da@github.com>
Message-ID: <Kj4eUHsEVJoYJLTG7eTiBVFd68yRljmoagn0pAEqPdI=.0c0cf9b7-9710-4802-9cce-aad8c0f35a71@github.com>

On Tue, 13 Jun 2023 19:59:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert 'main.help.opt.any.file' value for _de
>
> src/java.desktop/macosx/classes/com/apple/laf/resources/aqua_ja.properties line 63:
> 
>> 61: FileChooser.newFolderExistsError.textAndMnemonic=\u305D\u306E\u540D\u524D\u306F\u3059\u3067\u306B\u4F7F\u7528\u3055\u308C\u3066\u3044\u307E\u3059
>> 62: FileChooser.chooseButton.textAndMnemonic=\u9078\u629E
>> 63: FileChooser.chooseButtonToolTip.textAndMnemonic=\u9078\u629E\u3057\u305F\u30D5\u30A1\u30A4\u30EB\u3092\u8FFD\u52A0\u3057\u307E\u3059
> 
> Suggestion:
> 
> FileChooser.chooseButtonToolTip.textAndMnemonic=\u9078\u629e\u3055\u308c\u3066\u3044\u308b\u30d5\u30a1\u30a4\u30eb\u3092\u9078\u629e\u3057\u307e\u3059

Thank you Naoto, all your recommended translations have been updated. The HTML diffs have also been updated as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1228692234

From amenkov at openjdk.org  Tue Jun 13 22:05:03 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 13 Jun 2023 22:05:03 GMT
Subject: RFR: JDK-8306441: Two-stage Segmented Heap Dump [v8]
In-Reply-To: <u4pUhgtGiqkZrc1J8DG6uMRgxFuJqcuAcnwDqdgBYgM=.ba48997d-340a-428b-b94d-dfbab62f4287@github.com>
References: <8YqPPHSW4K1s0t317Kp6UqvoGuv5v9oCbjtQ9FX8p2o=.0f6c687b-d031-401d-901d-1ec532715cdc@github.com>
 <u4pUhgtGiqkZrc1J8DG6uMRgxFuJqcuAcnwDqdgBYgM=.ba48997d-340a-428b-b94d-dfbab62f4287@github.com>
Message-ID: <nvZ-o4g7TqoiXzTKiNJ9QW1jGTIrX69yVUl-wUquwwo=.e08b4a72-cc47-44b6-9ae9-1dabc3c89039@github.com>

On Tue, 6 Jun 2023 02:35:30 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> ### Motivation and proposal
>> Hi, heap dump brings about pauses for application's execution(STW), this is a well-known pain. JDK-8252842 have added parallel support to heapdump in an attempt to alleviate this issue. However, all concurrent threads competitively write heap data to the same file, and more memory is required to maintain the concurrent buffer queue. In experiments, we did not feel a significant performance improvement from that.
>> 
>> The minor-pause solution, which is presented in this PR, is a two-stage segmented heap dump:
>> 
>> 1. Stage One(STW): Concurrent threads directly write data to multiple heap files.
>> 2. Stage Two(Non-STW): Merge multiple heap files into one complete heap dump file.
>> 
>> Now concurrent worker threads are not required to maintain a buffer queue, which would result in more memory overhead, nor do they need to compete for locks.
>> 
>> ### Performance evaluation
>> | memory | numOfThread | STW         | Total      | Compression |
>> | --- | --------- | -------------- | ------------ | -------- |
>> | 8g | 1 thread | 15.612 secs | 15.612 secs | N |
>> | 8g | 32 thread |  2.5617250 secs | 14.498 secs | N |
>> | 8g | 32 thread | 2.3084878 secs | 3.198 secs | Compress1 |
>> | 8g | 32 thread | 10.9355128 secs | 21.882 secs | Compress2 |
>> | 8g | 96 thread | 2.6790452 secs | 14.012 secs | N |
>> | 8g | 96 thread | 2.3044796 secs | 3.589 secs | Compress1 |
>> | 8g | 96 thread | 9.7585151 secs | 20.219 secs| Compress2 |
>> | 16g | 1 thread | 26.278 secs | 26.278 secs | N |
>> | 16g | 32 thread |  5.2313740 secs | 26.417 secs | N |
>> | 16g | 32 thread | 5.6946983 secs | 6.538 secs | Compress1 |
>> | 16g | 32 thread | 21.8211105 secs | 41.133 secs | Compress2 |
>> | 16g | 96 thread | 6.2445556 secs | 27.141 secs | N |
>> | 16g | 96 thread | 4.6007096 secs | 6.259 secs | Compress1 |
>> | 16g | 96 thread | 19.2965783 secs |  39.007 secs | Compress2 |
>> | 32g | 1 thread | 48.149 secs | 48.149 secs | N |
>> | 32g | 32 thread | 10.7734677 secs | 61.643 secs | N |
>> | 32g | 32 thread | 10.1642097 secs | 10.903 secs | Compress1 |
>> | 32g | 32 thread | 43.8407607 secs | 88.152 secs | Compress2 |
>> | 32g | 96 thread | 13.1522042 secs | 61.432 secs | N |
>> | 32g | 96 thread | 9.0954641 secs | 9.885 secs | Compress1 |
>> | 32g | 96 thread | 38.9900931 secs | 80.574 secs | Compress2 |
>> | 64g | 1 thread |  100.583 secs | 100.583 secs | N |
>> | 64g | 32 thread | 20.9233744 secs | 134.701 secs | N |
>> | 64g | 32 thread | 18.5023784 secs | 19.358 secs | Compre...
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   undo refactor -- done

It looks good in general. I added some change requests.

src/hotspot/share/services/heapDumper.cpp line 577:

> 575:     _in_dump_segment = true;
> 576:     _is_huge_sub_record = len > buffer_size() - dump_segment_header_size;
> 577:     ResourceMark rm;

Looks like redundant leftover from development

src/hotspot/share/services/heapDumper.cpp line 1892:

> 1890: }
> 1891: 
> 1892: static int volatile dump_seq = 0;

Could you please convert this global variable to field of VM_HeapDumper.
The value can be passed to VM_HeapDumpMerge as ctor argument

src/hotspot/share/services/heapDumper.cpp line 1894:

> 1892: static int volatile dump_seq = 0;
> 1893: 
> 1894: void VM_HeapDumpMerge::merge_done() {

Implementation of VM_HeapDumpMerge methods is in the middle of VM_HeapDumper methods.
Please put them after VM_HeapDumpMerge declaration (as we have for all other classes)

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

PR Review: https://git.openjdk.org/jdk/pull/13667#pullrequestreview-1478097941
PR Review Comment: https://git.openjdk.org/jdk/pull/13667#discussion_r1228735182
PR Review Comment: https://git.openjdk.org/jdk/pull/13667#discussion_r1228728069
PR Review Comment: https://git.openjdk.org/jdk/pull/13667#discussion_r1228731666

From jlu at openjdk.org  Tue Jun 13 22:09:40 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 13 Jun 2023 22:09:40 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v4]
In-Reply-To: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
Message-ID: <G7xR-WlvhhX0aCPUxlEiRzZAlcYSAOI5wnUYZkIkqNQ=.d66f9290-6672-44fc-895d-d8ac6c872ed9@github.com>

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

Justin Lu has updated the pull request incrementally with three additional commits since the last revision:

 - Review: correct previous commit, remove ? as well
 - Review: Remove ?? from 'javac.opt.Xlint.desc.output-file-clash' for zh_CN
 - Review: Use old 'err.crash' zh_CN value

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14430/files
  - new: https://git.openjdk.org/jdk/pull/14430/files/7801eefb..f7c06512

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14430&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14430&range=02-03

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14430/head:pull/14430

PR: https://git.openjdk.org/jdk/pull/14430

From jlu at openjdk.org  Tue Jun 13 22:09:43 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 13 Jun 2023 22:09:43 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <YquJjfQ3DWo1mXUU9YXkfP0iYYnuuw11K4n-UmhEP9U=.fa39bf55-2813-422e-a84c-587f0ca40654@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
 <YquJjfQ3DWo1mXUU9YXkfP0iYYnuuw11K4n-UmhEP9U=.fa39bf55-2813-422e-a84c-587f0ca40654@github.com>
Message-ID: <eUpEuDxtBW4zFIazvfci4moBpPFzPDXyAkpgYNd4F9E=.61170e21-43a3-40d7-a5cc-fc9685a8a2e2@github.com>

On Tue, 13 Jun 2023 20:56:31 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert 'main.help.opt.any.file' value for _de
>
> Some comments:
> 
> - `src/java.base/share/classes/sun/launcher/resources/launcher`
> 
> `? private`. "private" should be translated, just like the "static" in the 2nd box.
> 
> - `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler`
> 
> `compiler.err.annotation.unrecognized.attribute.name`: Here "annotation" is translated to "??"? How do you translate "comment"?
> 
> `compiler.err.enum.label.must.be.enum.constant`: "constant" should be translated.
> 
> `compiler.warn.possible.this.escape`, `compiler.warn.possible.this.escape.location`: "escape" might not mean "??". It's more like its original meaning "run away" or "referenced".
> 
> 
> - `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac`:
> 
> `javac.opt.Xlint.desc.output-file-clash`: "native header files" is translated into "??????". The "??" is strange, I'd rather just say "???" as there is no non-native header file.
> 
> - `src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap`
> 
> I don't think the new translation is better than the old one.

Thank you for the review @wangweij,

I have addressed these recommendations

>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac`:
> 
> 
> `javac.opt.Xlint.desc.output-file-clash`: "native header files" is translated into "??????". The "??" is strange, I'd rather just say "???" as there is no non-native header file.
> 
>     * `src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap`
> 
> 
> I don't think the new translation is better than the old one.

For the other comments, I will bring them to the language specialist for updated translations. Ideally we can get those in for this translation drop, but if not, they can go in during the second translation drop during RDP2. 

I am also hesitant to make too many manual changes, as they will just get overwritten by the tool in the future, so it's best to get it fixed in the tool first.

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

PR Comment: https://git.openjdk.org/jdk/pull/14430#issuecomment-1590087839

From naoto at openjdk.org  Wed Jun 14 00:09:03 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 14 Jun 2023 00:09:03 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v4]
In-Reply-To: <G7xR-WlvhhX0aCPUxlEiRzZAlcYSAOI5wnUYZkIkqNQ=.d66f9290-6672-44fc-895d-d8ac6c872ed9@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <G7xR-WlvhhX0aCPUxlEiRzZAlcYSAOI5wnUYZkIkqNQ=.d66f9290-6672-44fc-895d-d8ac6c872ed9@github.com>
Message-ID: <sGkMLbM6Iyp04SnzPdG_CLR9wMlzypOQwrpdy_9iheM=.1f136a3d-f264-42a2-85e5-c4506564eb74@github.com>

On Tue, 13 Jun 2023 22:09:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
>> 
>> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
>> 
>> For example,
>> 
>> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
>> 
>> 
>> Please note that the HTML files only apply to .properties, and not .java resources.
>
> Justin Lu has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Review: correct previous commit, remove ? as well
>  - Review: Remove ?? from 'javac.opt.Xlint.desc.output-file-clash' for zh_CN
>  - Review: Use old 'err.crash' zh_CN value

Looks good, Justin

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14430#pullrequestreview-1478236336

From iklam at openjdk.org  Wed Jun 14 00:19:03 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 14 Jun 2023 00:19:03 GMT
Subject: RFR: 8309878: Reduce inclusion of resolvedIndyEntry.hpp
In-Reply-To: <taQIbPhd950L1P5fndoELzvpKdKegJ6rJrwprn6DqWs=.f8da1da8-4fec-472d-9669-cd177377fdb8@github.com>
References: <ngayct8s671hMXh-nM2Geo7wUpvGqDOzu4gvZr97Mzg=.b6a417c2-13f4-48e1-abef-743ac4966e6d@github.com>
 <taQIbPhd950L1P5fndoELzvpKdKegJ6rJrwprn6DqWs=.f8da1da8-4fec-472d-9669-cd177377fdb8@github.com>
Message-ID: <ARFe2-g0Mkw3_e9V5fL5ZyBBkxpxMxVWWA7OFNwKgtc=.b0ac9b83-ec43-4374-ae4b-47eaa3cfa465@github.com>

On Mon, 12 Jun 2023 22:24:26 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> resolvedIndyEntry.hpp was added in [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995) and is included in the popular cpCache.hpp. As a result, resolvedIndyEntry.hpp is included in 807 out of about 1160 hotspot .o files.
>> 
>> The contents of resolvedIndyEntry.hpp is infrequently used. Its inclusion should be moved from cpCache.hpp to cpCache.inline.hpp. This improves hotspot build time.
>> 
>> After this PR, resolvedIndyEntry.hpp is included in only 30 hotspot .o files.
>
> Looks good.
> Thanks,
> Serguei

Thanks @sspitsyn @coleenp @matias9927 for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/14427#issuecomment-1590238854

From iklam at openjdk.org  Wed Jun 14 00:19:05 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 14 Jun 2023 00:19:05 GMT
Subject: Integrated: 8309878: Reduce inclusion of resolvedIndyEntry.hpp
In-Reply-To: <ngayct8s671hMXh-nM2Geo7wUpvGqDOzu4gvZr97Mzg=.b6a417c2-13f4-48e1-abef-743ac4966e6d@github.com>
References: <ngayct8s671hMXh-nM2Geo7wUpvGqDOzu4gvZr97Mzg=.b6a417c2-13f4-48e1-abef-743ac4966e6d@github.com>
Message-ID: <iH-JdOEMCordoQfGRDJ9DgeKmdlP2RM1-2c1U4-6LYU=.c8642e7a-3666-43d5-b97a-fdaf32711fe1@github.com>

On Mon, 12 Jun 2023 19:52:36 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> resolvedIndyEntry.hpp was added in [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995) and is included in the popular cpCache.hpp. As a result, resolvedIndyEntry.hpp is included in 807 out of about 1160 hotspot .o files.
> 
> The contents of resolvedIndyEntry.hpp is infrequently used. Its inclusion should be moved from cpCache.hpp to cpCache.inline.hpp. This improves hotspot build time.
> 
> After this PR, resolvedIndyEntry.hpp is included in only 30 hotspot .o files.

This pull request has now been integrated.

Changeset: 5d193193
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5d193193a3a4c519e7b3d77b27e6b2bf1b11c7f9
Stats:     86 lines in 35 files changed: 61 ins; 13 del; 12 mod

8309878: Reduce inclusion of resolvedIndyEntry.hpp

Reviewed-by: coleenp, sspitsyn, matsaave

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

PR: https://git.openjdk.org/jdk/pull/14427

From amenkov at openjdk.org  Wed Jun 14 01:20:56 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 14 Jun 2023 01:20:56 GMT
Subject: RFR: 8309663: test fails
 "assert(check_alignment(result)) failed: address not aligned:
 0x00000008baadbabe"
In-Reply-To: <fqPCs7pEUNY9ODLKOspB5buuBWtDPfKmouI8p05KBKw=.16dec9bd-ca79-41ef-808f-4967073151d2@github.com>
References: <fqPCs7pEUNY9ODLKOspB5buuBWtDPfKmouI8p05KBKw=.16dec9bd-ca79-41ef-808f-4967073151d2@github.com>
Message-ID: <KzkpvKHgFEo5FnXPzluO5r3rSDjx6EIzc_Oq3uj5_Z0=.40009d56-5406-46a6-8ab9-048ba7c822c0@github.com>

On Wed, 14 Jun 2023 01:02:09 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> If virtual thread has frames in stackChunks, need to apply load barriers before processing nmethods (javaVFrame::locals() and javaVFrame::expressions() do it internally)
> 
> Testing: tier1-tier5 (still in progress);
> 400 runs of VThreadStackRefTest.java test on linux-x64 and linux-x64-debug with "-XX:+UseZGC -Xcomp -XX:-TieredCompilation"

added serviceability as it was not added automatically

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

PR Comment: https://git.openjdk.org/jdk/pull/14460#issuecomment-1590288091

From dholmes at openjdk.org  Wed Jun 14 05:22:19 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 14 Jun 2023 05:22:19 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
Message-ID: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>

Updated the version to 22-ea and year to 2024.

The following unpublished changes will also be included in this update:
- [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
- [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
- [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option

The following changes were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22:
- [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code
- [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor

Thanks.

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

Commit messages:
 - 8304478: Initial nroff manpage generation for JDK 22

Changes: https://git.openjdk.org/jdk/pull/14462/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14462&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304478
  Stats: 140 lines in 28 files changed: 1 ins; 105 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/14462.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14462/head:pull/14462

PR: https://git.openjdk.org/jdk/pull/14462

From alanb at openjdk.org  Wed Jun 14 06:11:55 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 14 Jun 2023 06:11:55 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
Message-ID: <u7cexPiA_MtAjwCteuLZ8dx5RxqHvokGd62Tq9SGUlA=.4aac4c19-e2af-492d-9c06-f8b8d44d11a3@github.com>

On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Updated the version to 22-ea and year to 2024.
> 
> The following unpublished changes will also be included in this update:
> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22:
> - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code
> - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor
> 
> Thanks.

Looks fine.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14462#pullrequestreview-1478549017

From dholmes at openjdk.org  Wed Jun 14 06:11:55 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 14 Jun 2023 06:11:55 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <u7cexPiA_MtAjwCteuLZ8dx5RxqHvokGd62Tq9SGUlA=.4aac4c19-e2af-492d-9c06-f8b8d44d11a3@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
 <u7cexPiA_MtAjwCteuLZ8dx5RxqHvokGd62Tq9SGUlA=.4aac4c19-e2af-492d-9c06-f8b8d44d11a3@github.com>
Message-ID: <W9Zscls7-cKxv0kjUNUgbwnOWOEWCiCfaXX9xsXjOug=.3406ce3f-a12c-40b0-aeeb-a2598dcf299e@github.com>

On Wed, 14 Jun 2023 06:08:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Updated the version to 22-ea and year to 2024.
>> 
>> The following unpublished changes will also be included in this update:
>> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
>> - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
>> - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
>> 
>> The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22:
>> - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code
>> - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor
>> 
>> Thanks.
>
> Looks fine.

Thanks @AlanBateman !

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

PR Comment: https://git.openjdk.org/jdk/pull/14462#issuecomment-1590531861

From yyang at openjdk.org  Wed Jun 14 06:24:28 2023
From: yyang at openjdk.org (Yi Yang)
Date: Wed, 14 Jun 2023 06:24:28 GMT
Subject: RFR: JDK-8306441: Two-stage Segmented Heap Dump [v9]
In-Reply-To: <8YqPPHSW4K1s0t317Kp6UqvoGuv5v9oCbjtQ9FX8p2o=.0f6c687b-d031-401d-901d-1ec532715cdc@github.com>
References: <8YqPPHSW4K1s0t317Kp6UqvoGuv5v9oCbjtQ9FX8p2o=.0f6c687b-d031-401d-901d-1ec532715cdc@github.com>
Message-ID: <09RatXWCXaKcJ0qGCB1AjpYwhMvCrpAL1WIu7BXZH6c=.5cae9e7c-719f-461b-9c31-b92d46a9cccc@github.com>

> ### Motivation and proposal
> Hi, heap dump brings about pauses for application's execution(STW), this is a well-known pain. JDK-8252842 have added parallel support to heapdump in an attempt to alleviate this issue. However, all concurrent threads competitively write heap data to the same file, and more memory is required to maintain the concurrent buffer queue. In experiments, we did not feel a significant performance improvement from that.
> 
> The minor-pause solution, which is presented in this PR, is a two-stage segmented heap dump:
> 
> 1. Stage One(STW): Concurrent threads directly write data to multiple heap files.
> 2. Stage Two(Non-STW): Merge multiple heap files into one complete heap dump file.
> 
> Now concurrent worker threads are not required to maintain a buffer queue, which would result in more memory overhead, nor do they need to compete for locks. The changes in the overall design are as follows:
> 
> ![image](https://github.com/openjdk/jdk/assets/5010047/86d2717d-c621-446f-98c2-cce761ec8db5)
> <p align="center">Fig1. Before</p>
> 
> ![image](https://github.com/openjdk/jdk/assets/5010047/c912c516-83b6-4343-a2e8-5d5bdb99cb87)
> <p align="center">Fig1. After this patch</p>
> 
> ### Performance evaluation
> | memory | numOfThread | STW         | Total      | Compression |
> | --- | --------- | -------------- | ------------ | -------- |
> | 8g | 1 thread | 15.612 secs | 15.612 secs | N |
> | 8g | 32 thread |  2.5617250 secs | 14.498 secs | N |
> | 8g | 32 thread | 2.3084878 secs | 3.198 secs | Compress1 |
> | 8g | 32 thread | 10.9355128 secs | 21.882 secs | Compress2 |
> | 8g | 96 thread | 2.6790452 secs | 14.012 secs | N |
> | 8g | 96 thread | 2.3044796 secs | 3.589 secs | Compress1 |
> | 8g | 96 thread | 9.7585151 secs | 20.219 secs| Compress2 |
> | 16g | 1 thread | 26.278 secs | 26.278 secs | N |
> | 16g | 32 thread |  5.2313740 secs | 26.417 secs | N |
> | 16g | 32 thread | 5.6946983 secs | 6.538 secs | Compress1 |
> | 16g | 32 thread | 21.8211105 secs | 41.133 secs | Compress2 |
> | 16g | 96 thread | 6.2445556 secs | 27.141 secs | N |
> | 16g | 96 thread | 4.6007096 secs | 6.259 secs | Compress1 |
> | 16g | 96 thread | 19.2965783 secs |  39.007 secs | Compress2 |
> | 32g | 1 thread | 48.149 secs | 48.149 secs | N |
> | 32g | 32 thread | 10.7734677 secs | 61.643 secs | N |
> | 32g | 32 thread | 10.1642097 secs | 10.903 secs | Compress1 |
> | 32g | 32 thread | 43.8407607 secs | 88.152 secs | Compress2 |
> | 32g | 96 thread | 13.1522042 secs | 61.432 secs | N |
> | 32g | 96 thread | 9.0954641 secs | 9.885 secs | C...

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  review from Alex

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13667/files
  - new: https://git.openjdk.org/jdk/pull/13667/files/c8e80e9e..04f54d9a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13667&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13667&range=07-08

  Stats: 152 lines in 1 file changed: 78 ins; 70 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/13667.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13667/head:pull/13667

PR: https://git.openjdk.org/jdk/pull/13667

From yyang at openjdk.org  Wed Jun 14 06:54:10 2023
From: yyang at openjdk.org (Yi Yang)
Date: Wed, 14 Jun 2023 06:54:10 GMT
Subject: RFR: JDK-8306441: Two-stage Segmented Heap Dump [v10]
In-Reply-To: <8YqPPHSW4K1s0t317Kp6UqvoGuv5v9oCbjtQ9FX8p2o=.0f6c687b-d031-401d-901d-1ec532715cdc@github.com>
References: <8YqPPHSW4K1s0t317Kp6UqvoGuv5v9oCbjtQ9FX8p2o=.0f6c687b-d031-401d-901d-1ec532715cdc@github.com>
Message-ID: <ZrfI7J1hP2Sekrm8mJwoCWbcz73iCuQc5WfyhmSOuz0=.558fad8d-019d-4552-bb0f-cbc4acc0c36c@github.com>

> ### Motivation and proposal
> Hi, heap dump brings about pauses for application's execution(STW), this is a well-known pain. JDK-8252842 have added parallel support to heapdump in an attempt to alleviate this issue. However, all concurrent threads competitively write heap data to the same file, and more memory is required to maintain the concurrent buffer queue. In experiments, we did not feel a significant performance improvement from that.
> 
> The minor-pause solution, which is presented in this PR, is a two-stage segmented heap dump:
> 
> 1. Stage One(STW): Concurrent threads directly write data to multiple heap files.
> 2. Stage Two(Non-STW): Merge multiple heap files into one complete heap dump file.
> 
> Now concurrent worker threads are not required to maintain a buffer queue, which would result in more memory overhead, nor do they need to compete for locks. The changes in the overall design are as follows:
> 
> ![image](https://github.com/openjdk/jdk/assets/5010047/86d2717d-c621-446f-98c2-cce761ec8db5)
> <p align="center">Fig1. Before</p>
> 
> ![image](https://github.com/openjdk/jdk/assets/5010047/c912c516-83b6-4343-a2e8-5d5bdb99cb87)
> <p align="center">Fig1. After this patch</p>
> 
> ### Performance evaluation
> | memory | numOfThread | STW         | Total      | Compression |
> | --- | --------- | -------------- | ------------ | -------- |
> | 8g | 1 thread | 15.612 secs | 15.612 secs | N |
> | 8g | 32 thread |  2.5617250 secs | 14.498 secs | N |
> | 8g | 32 thread | 2.3084878 secs | 3.198 secs | Compress1 |
> | 8g | 32 thread | 10.9355128 secs | 21.882 secs | Compress2 |
> | 8g | 96 thread | 2.6790452 secs | 14.012 secs | N |
> | 8g | 96 thread | 2.3044796 secs | 3.589 secs | Compress1 |
> | 8g | 96 thread | 9.7585151 secs | 20.219 secs| Compress2 |
> | 16g | 1 thread | 26.278 secs | 26.278 secs | N |
> | 16g | 32 thread |  5.2313740 secs | 26.417 secs | N |
> | 16g | 32 thread | 5.6946983 secs | 6.538 secs | Compress1 |
> | 16g | 32 thread | 21.8211105 secs | 41.133 secs | Compress2 |
> | 16g | 96 thread | 6.2445556 secs | 27.141 secs | N |
> | 16g | 96 thread | 4.6007096 secs | 6.259 secs | Compress1 |
> | 16g | 96 thread | 19.2965783 secs |  39.007 secs | Compress2 |
> | 32g | 1 thread | 48.149 secs | 48.149 secs | N |
> | 32g | 32 thread | 10.7734677 secs | 61.643 secs | N |
> | 32g | 32 thread | 10.1642097 secs | 10.903 secs | Compress1 |
> | 32g | 32 thread | 43.8407607 secs | 88.152 secs | Compress2 |
> | 32g | 96 thread | 13.1522042 secs | 61.432 secs | N |
> | 32g | 96 thread | 9.0954641 secs | 9.885 secs | C...

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13667/files
  - new: https://git.openjdk.org/jdk/pull/13667/files/04f54d9a..2280159a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13667&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13667&range=08-09

  Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13667.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13667/head:pull/13667

PR: https://git.openjdk.org/jdk/pull/13667

From sspitsyn at openjdk.org  Wed Jun 14 09:10:59 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 14 Jun 2023 09:10:59 GMT
Subject: RFR: 8309663: test fails
 "assert(check_alignment(result)) failed: address not aligned:
 0x00000008baadbabe"
In-Reply-To: <fqPCs7pEUNY9ODLKOspB5buuBWtDPfKmouI8p05KBKw=.16dec9bd-ca79-41ef-808f-4967073151d2@github.com>
References: <fqPCs7pEUNY9ODLKOspB5buuBWtDPfKmouI8p05KBKw=.16dec9bd-ca79-41ef-808f-4967073151d2@github.com>
Message-ID: <Q5PaUjdpGBvTADcC1vItvofC1VMICsdSYvoVsTslqzA=.e03a47a5-a331-4d13-b622-f203e3430404@github.com>

On Wed, 14 Jun 2023 01:02:09 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> If virtual thread has frames in stackChunks, need to apply load barriers before processing nmethods (javaVFrame::locals() and javaVFrame::expressions() do it internally)
> 
> Testing: tier1-tier5 (still in progress);
> 400 runs of VThreadStackRefTest.java test on linux-x64 and linux-x64-debug with "-XX:+UseZGC -Xcomp -XX:-TieredCompilation"

src/hotspot/share/prims/jvmtiTagMap.cpp line 2325:

> 2323:         // Need to apply load barriers for unmounted vthreads.
> 2324:         nmethod* nm = jvf->cb()->as_nmethod();
> 2325:         nm->run_nmethod_entry_barrier();

This looks good in general.
However, I'm looking at the `stackChunkOopDesc::do_barriers0()` implementation and wonder if a similar trick is needed for interpreter frames (to support `Class Redefinition`):

template <stackChunkOopDesc::BarrierType barrier, ChunkFrames frame_kind, typename RegisterMapT>
void stackChunkOopDesc::do_barriers0(const StackChunkFrameStream<frame_kind>& f, const RegisterMapT* map) {
  // We need to invoke the write barriers so as not to miss oops in old chunks that haven't yet been concurrently scanned
  assert (!f.is_done(), "");

  if (f.is_interpreted()) {
    Method* m = f.to_frame().interpreter_frame_method();
    // Class redefinition support
    m->record_gc_epoch();
  } else if (f.is_compiled()) {
    nmethod* nm = f.cb()->as_nmethod();
    // The entry barrier takes care of having the right synchronization
    // when keeping the nmethod alive during concurrent execution.
    nm->run_nmethod_entry_barrier();
    // There is no need to mark the Method, as class redefinition will walk the
    // CodeCache, noting their Methods
  }
  . . .

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14460#discussion_r1229273861

From sspitsyn at openjdk.org  Wed Jun 14 09:28:11 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 14 Jun 2023 09:28:11 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
Message-ID: <PzXXmQJzScDG52LEySE0srWf3GF5QkLDolW9Vd-WHCg=.41a493c7-cc28-4f11-9687-ff1857171380@github.com>

On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Updated the version to 22-ea and year to 2024.
> 
> The following unpublished changes will also be included in this update:
> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22:
> - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code
> - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor
> 
> Thanks.

The Serviceability changes look good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14462#pullrequestreview-1478940868

From kevinw at openjdk.org  Wed Jun 14 11:47:13 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 14 Jun 2023 11:47:13 GMT
Subject: RFR: 8303916: ThreadLists.java inconsistent results
Message-ID: <H3WNK3qa7r4NXwPkjzAo8kIgus6c9VedG5F64t0plH8=.762a0531-40da-4f1c-8ba2-acd278417e30@github.com>

This test fails when additional threads are created, as it compares thread lists from different sources and sees a mismatch.

It needs to tolerate some threads with certain names appearing, e.g. JVMCI and ForkJoin threads.  If there are extra threads in the thread ID list from the ThreadMBean, remove them from the thread count before comparing.

When it fails, additionally print the ids and names of threads that it got from the MBean.

I found the test quite confusing, the naming of thread counts, arrays of threads, and arrays of thread stacktraces from different sources, so have renamed some things.

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

Commit messages:
 - More concise printing of thread id+name on failure.
 - Merge remote-tracking branch 'upstream/master' into 8303916_ThreadLists_test
 - 8303916: ThreadLists.java inconsistent results

Changes: https://git.openjdk.org/jdk/pull/14465/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14465&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303916
  Stats: 77 lines in 1 file changed: 54 ins; 1 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/14465.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14465/head:pull/14465

PR: https://git.openjdk.org/jdk/pull/14465

From jlu at openjdk.org  Wed Jun 14 16:25:00 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 14 Jun 2023 16:25:00 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <05VweeA-JZy6fvHzscLEDLi4nPZM0xhDiaOqYcceMgI=.2574b0d1-92ea-4319-9c45-dbd9df91ad4f@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
 <LQj9A4_3dfSUIozPcVuYCUF1QhseODhxAft9eKH33E4=.30cf5fee-d616-4726-8c33-1b22bfb29c26@github.com>
 <05VweeA-JZy6fvHzscLEDLi4nPZM0xhDiaOqYcceMgI=.2574b0d1-92ea-4319-9c45-dbd9df91ad4f@github.com>
Message-ID: <i2xpAM4Cbkg3wxLwU6xXUsAerpA3w3n1wHE9BFFtI0Q=.49a5cd2b-b201-4322-af3a-dd198470a544@github.com>

On Tue, 13 Jun 2023 18:50:42 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties line 140:
>> 
>>> 138: 
>>> 139: # 0: type, 1: name
>>> 140: compiler.err.annotation.unrecognized.attribute.name=Annotation @{0} weist das unbekannte Attribut "{1}" auf
>> 
>> Is it intentional to replace single quotes with double quotes? It is done in several locations in this file, but other languages keep using single quotes as in the source English resource file.
>
> I will consult the language specialist on this. I remember in previous discussions that certain languages would format punctuation differently, but let me ask about this specific instance.

The language specialist confirmed the double quotes are locale specific for de.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14430#discussion_r1229881212

From mchung at openjdk.org  Wed Jun 14 18:43:57 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 14 Jun 2023 18:43:57 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
Message-ID: <K4hEuZ0tOGwmXOhjV3akufh4EWm7Ssj9tehW3-UV3uc=.804e1b1b-c860-4529-ae56-ada4ce326c95@github.com>

On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Updated the version to 22-ea and year to 2024.
> 
> The following unpublished changes will also be included in this update:
> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22:
> - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code
> - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor
> 
> Thanks.

Marked as reviewed by mchung (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14462#pullrequestreview-1480088199

From lancea at openjdk.org  Wed Jun 14 18:51:10 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 14 Jun 2023 18:51:10 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
Message-ID: <pun50s0fljjG983cJ983N7coIJWbOdKdcT6LhkbOdK4=.bad2c612-56ee-45c9-a6c3-89203e19aa4d@github.com>

On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Updated the version to 22-ea and year to 2024.
> 
> The following unpublished changes will also be included in this update:
> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22:
> - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code
> - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor
> 
> Thanks.

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14462#pullrequestreview-1480097706

From acobbs at openjdk.org  Wed Jun 14 19:23:59 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 14 Jun 2023 19:23:59 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
Message-ID: <Noerq3rS8D4QNDDDLvsnFqlW___-A39CSFOJnBFsB8Q=.d9610bac-89ca-43a4-82d0-08cd97d38163@github.com>

On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The following changes, to javac.1, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22

Just curious, since you have access to the secret closed sources, can you not backport these changes yourself? Instead of just deleting them and expecting someone else to rescue them from oblivion?

To be clear, I'm not blaming you for this situation - the problem is that there exist "closed sources" at all (why??) - but that doesn't seem like a good excuse for deleting work without a clear path to ensuring it is preserved (and the simplest way to do that is to do it yourself). Obviously I'd do it myself if I could.

Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/14462#issuecomment-1591849483

From amenkov at openjdk.org  Wed Jun 14 19:31:04 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 14 Jun 2023 19:31:04 GMT
Subject: RFR: 8309663: test fails
 "assert(check_alignment(result)) failed: address not aligned:
 0x00000008baadbabe"
In-Reply-To: <Q5PaUjdpGBvTADcC1vItvofC1VMICsdSYvoVsTslqzA=.e03a47a5-a331-4d13-b622-f203e3430404@github.com>
References: <fqPCs7pEUNY9ODLKOspB5buuBWtDPfKmouI8p05KBKw=.16dec9bd-ca79-41ef-808f-4967073151d2@github.com>
 <Q5PaUjdpGBvTADcC1vItvofC1VMICsdSYvoVsTslqzA=.e03a47a5-a331-4d13-b622-f203e3430404@github.com>
Message-ID: <E2U5bfawmMjCgzqe9pnzCBsL32YGRPcJUQ-ECswmLiY=.3cd140e7-1118-4485-9b32-822fa0af8f33@github.com>

On Wed, 14 Jun 2023 09:07:37 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This looks good in general. However, I'm looking at the `stackChunkOopDesc::do_barriers0()` implementation and wonder if a similar trick is needed for interpreter frames (to support `Class Redefinition`):
> 

This code collects references from thread stack, I don't see how class redefinition can affect them

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14460#discussion_r1230074035

From cjplummer at openjdk.org  Wed Jun 14 19:35:56 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 14 Jun 2023 19:35:56 GMT
Subject: RFR: 8303916: ThreadLists.java inconsistent results
In-Reply-To: <H3WNK3qa7r4NXwPkjzAo8kIgus6c9VedG5F64t0plH8=.762a0531-40da-4f1c-8ba2-acd278417e30@github.com>
References: <H3WNK3qa7r4NXwPkjzAo8kIgus6c9VedG5F64t0plH8=.762a0531-40da-4f1c-8ba2-acd278417e30@github.com>
Message-ID: <Qd20vN4PmraGcUxFtawnNki9AXvYtQcsrFtYFSHV8Sw=.9e4e92e5-6ea4-4c03-a976-4eacf3f74f29@github.com>

On Wed, 14 Jun 2023 09:30:49 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test fails when additional threads are created, as it compares thread lists from different sources and sees a mismatch.
> 
> It needs to tolerate some threads with certain names appearing, e.g. JVMCI and ForkJoin threads.  If there are extra threads in the thread ID list from the ThreadMBean, remove them from the thread count before comparing.
> 
> When it fails, additionally print the ids and names of threads that it got from the MBean.
> 
> I found the test quite confusing, the naming of thread counts, arrays of threads, and arrays of thread stacktraces from different sources, so have renamed some things.

Overall looks good, but I'm surprised you only need to filter "ForkJoinPool" and "JVMCI". What about threads like "Common-Cleaner"? 

https://github.com/openjdk/jdk/blob/57b8251241e2044d5039ce162bf4637a9b2e5466/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/EventFilters.java#L333

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

PR Review: https://git.openjdk.org/jdk/pull/14465#pullrequestreview-1480164185

From kevinw at openjdk.org  Wed Jun 14 19:46:57 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 14 Jun 2023 19:46:57 GMT
Subject: RFR: 8303916: ThreadLists.java inconsistent results
In-Reply-To: <H3WNK3qa7r4NXwPkjzAo8kIgus6c9VedG5F64t0plH8=.762a0531-40da-4f1c-8ba2-acd278417e30@github.com>
References: <H3WNK3qa7r4NXwPkjzAo8kIgus6c9VedG5F64t0plH8=.762a0531-40da-4f1c-8ba2-acd278417e30@github.com>
Message-ID: <PgkblCLHazdyU7zQnn7b5v47pmvm0yQ8SsinQDOeD9g=.b57a83d1-105f-4204-86fe-e16f744a3023@github.com>

On Wed, 14 Jun 2023 09:30:49 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test fails when additional threads are created, as it compares thread lists from different sources and sees a mismatch.
> 
> It needs to tolerate some threads with certain names appearing, e.g. JVMCI and ForkJoin threads.  If there are extra threads in the thread ID list from the ThreadMBean, remove them from the thread count before comparing.
> 
> When it fails, additionally print the ids and names of threads that it got from the MBean.
> 
> I found the test quite confusing, the naming of thread counts, arrays of threads, and arrays of thread stacktraces from different sources, so have renamed some things.

> 

Thanks - that's a useful reference list.  For this test, it's never managed to not have Common-Cleaner in the initial set of threads it observes, I think...  But it's very easy to see a couple of ForkJoinPool-x-worker-x threads, and see one more of them by the time it gets threads from the MXBean.  That's the way I see it failing for us now.  If we do see others appear, I hope having added the extra printing it will be easy to add other names, if they affect this test...

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

PR Comment: https://git.openjdk.org/jdk/pull/14465#issuecomment-1591874809

From dholmes at openjdk.org  Wed Jun 14 21:31:00 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 14 Jun 2023 21:31:00 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <Noerq3rS8D4QNDDDLvsnFqlW___-A39CSFOJnBFsB8Q=.d9610bac-89ca-43a4-82d0-08cd97d38163@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
 <Noerq3rS8D4QNDDDLvsnFqlW___-A39CSFOJnBFsB8Q=.d9610bac-89ca-43a4-82d0-08cd97d38163@github.com>
Message-ID: <BLpvFy8u6sXytaJhhmA_Fa3I3ITTlixJsRyfkv5ASyc=.ee363700-c516-46e4-b10d-d9490615b802@github.com>

On Wed, 14 Jun 2023 19:21:01 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Just curious, since you have access to the secret closed sources, can you not backport these changes yourself? Instead of just deleting them and expecting someone else to rescue them from oblivion?

@archiecobbs  we (Oracle) will take care of restoring this text so please don't be concerned about that. It will just be a temporary glitch. It should have been handled when the original PRs were done. It needs to be handled as a separate issue and PR though - whether that were to happen before or after this PR is somewhat immaterial.

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

PR Comment: https://git.openjdk.org/jdk/pull/14462#issuecomment-1592014026

From dholmes at openjdk.org  Wed Jun 14 21:31:03 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 14 Jun 2023 21:31:03 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <PzXXmQJzScDG52LEySE0srWf3GF5QkLDolW9Vd-WHCg=.41a493c7-cc28-4f11-9687-ff1857171380@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
 <PzXXmQJzScDG52LEySE0srWf3GF5QkLDolW9Vd-WHCg=.41a493c7-cc28-4f11-9687-ff1857171380@github.com>
Message-ID: <RN3gF2SqClnHGc2V8rBkDumSLXd4Tab0-oCaO3rQ0TA=.d59d4324-c7b6-44e8-8be6-088e7c0b3a52@github.com>

On Wed, 14 Jun 2023 09:25:14 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Updated the version to 22-ea and year to 2024.
>> 
>> The following unpublished changes will also be included in this update:
>> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
>> - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
>> - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
>> 
>> The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22:
>> - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code
>> - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor
>> 
>> Thanks.
>
> The Serviceability changes look good.
> Thanks,
> Serguei

Thanks for the additional reviews @sspitsyn , @LanceAndersen  and @mlchung !

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

PR Comment: https://git.openjdk.org/jdk/pull/14462#issuecomment-1592014943

From cjplummer at openjdk.org  Wed Jun 14 21:32:09 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 14 Jun 2023 21:32:09 GMT
Subject: RFR: 8308499: Test
 vmTestbase/nsk/jdi/MethodExitRequest/addClassExclusionFilter/filter001/TestDescription.java
 failed: VMDisconnectedException
Message-ID: <-0tDx5i1vrT6MQiPY9ZzRMVE6SibI7vqOJMjPuGywqU=.b25f2536-bfbf-4754-a56d-05f5a73fd3ba@github.com>

The test gets overloaded with MethodExitEvents, causing them to queue up (in the JDI queue) and continue to be processed by the test after the debuggee exits. This results in a VMDisconnectedException when the test tries to do the following after getting an event:

`    String str = ((MethodExitEvent)event).location().declaringType().name(); `

The test is suppose to add filters to execlude events for all non-test classes, but it is only filtering `java.*` and `sun.*`. There are also a very large number of `jdk.*` events coming in, and this is what is causing the event backlog and the processing of events after disconnect. Filtering out `jdk.*` events reduces the total number of events to a few dozen, and the test passes.

More details can be found in the CR.

Testing in progress: tier5 svc testing, and also running the failing test on all platforms (both debug and product).

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

Commit messages:
 - filter jdk.* clases

Changes: https://git.openjdk.org/jdk/pull/14480/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14480&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308499
  Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14480.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14480/head:pull/14480

PR: https://git.openjdk.org/jdk/pull/14480

From acobbs at openjdk.org  Wed Jun 14 21:40:57 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 14 Jun 2023 21:40:57 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <BLpvFy8u6sXytaJhhmA_Fa3I3ITTlixJsRyfkv5ASyc=.ee363700-c516-46e4-b10d-d9490615b802@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
 <Noerq3rS8D4QNDDDLvsnFqlW___-A39CSFOJnBFsB8Q=.d9610bac-89ca-43a4-82d0-08cd97d38163@github.com>
 <BLpvFy8u6sXytaJhhmA_Fa3I3ITTlixJsRyfkv5ASyc=.ee363700-c516-46e4-b10d-d9490615b802@github.com>
Message-ID: <okk5G3GqQV8MOBuFOOfytJMRx9WMoL0s19P8GBKXnUE=.ad36d5f6-ec18-4e0e-824a-bef478f66bd5@github.com>

On Wed, 14 Jun 2023 21:28:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > Just curious, since you have access to the secret closed sources, can you not backport these changes yourself? Instead of just deleting them and expecting someone else to rescue them from oblivion?
> 
> @archiecobbs we (Oracle) will take care of restoring this text so please don't be concerned about that. It will just be a temporary glitch. 

OK thanks. Putting my trust in you :)

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

PR Comment: https://git.openjdk.org/jdk/pull/14462#issuecomment-1592023452

From lmesnik at openjdk.org  Wed Jun 14 21:56:56 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 14 Jun 2023 21:56:56 GMT
Subject: RFR: 8308499: Test
 vmTestbase/nsk/jdi/MethodExitRequest/addClassExclusionFilter/filter001/TestDescription.java
 failed: VMDisconnectedException
In-Reply-To: <-0tDx5i1vrT6MQiPY9ZzRMVE6SibI7vqOJMjPuGywqU=.b25f2536-bfbf-4754-a56d-05f5a73fd3ba@github.com>
References: <-0tDx5i1vrT6MQiPY9ZzRMVE6SibI7vqOJMjPuGywqU=.b25f2536-bfbf-4754-a56d-05f5a73fd3ba@github.com>
Message-ID: <NU8_ylDcVvFs_bs5W1MpqnSv8MgItBOlVdqgW7PpzI8=.7c2092d1-726c-499a-911b-f3c0101e5873@github.com>

On Wed, 14 Jun 2023 21:24:31 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The test gets overloaded with MethodExitEvents, causing them to queue up (in the JDI queue) and continue to be processed by the test after the debuggee exits. This results in a VMDisconnectedException when the test tries to do the following after getting an event:
> 
> `    String str = ((MethodExitEvent)event).location().declaringType().name(); `
> 
> The test is suppose to add filters to execlude events for all non-test classes, but it is only filtering `java.*` and `sun.*`. There are also a very large number of `jdk.*` events coming in, and this is what is causing the event backlog and the processing of events after disconnect. Filtering out `jdk.*` events reduces the total number of events to a few dozen, and the test passes.
> 
> More details can be found in the CR.
> 
> Testing in progress: tier5 svc testing, and also running the failing test on all platforms (both debug and product).

Changes requested by lmesnik (Reviewer).

test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addClassExclusionFilter/filter001.java line 77:

> 75:     private String classExclName1 = "java";
> 76:     private String classExclName2 = "sun";
> 77:     private String classExclName3 = "jdk";

The fix is reasonable. However,
I think it would be better to use List<String> with List.of(...) and list.contains() to filter exclusions.

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

PR Review: https://git.openjdk.org/jdk/pull/14480#pullrequestreview-1480363171
PR Review Comment: https://git.openjdk.org/jdk/pull/14480#discussion_r1230209088

From dholmes at openjdk.org  Wed Jun 14 22:11:57 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 14 Jun 2023 22:11:57 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
Message-ID: <KXanlp-XRQ3wM7NK9pRkfFdQdHZB6UzXYETEpBqd2J4=.08b3dc2b-34df-481f-b99a-9a14b715e6de@github.com>

On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Updated the version to 22-ea and year to 2024.
> 
> The following unpublished changes will also be included in this update:
> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22:
> - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code
> - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor
> 
> Thanks.

I've filed https://bugs.openjdk.org/browse/JDK-8310067 for the javac manpage fixup.

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

PR Comment: https://git.openjdk.org/jdk/pull/14462#issuecomment-1592056009

From dholmes at openjdk.org  Thu Jun 15 02:17:15 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 15 Jun 2023 02:17:15 GMT
Subject: RFR: 8303916: ThreadLists.java inconsistent results
In-Reply-To: <H3WNK3qa7r4NXwPkjzAo8kIgus6c9VedG5F64t0plH8=.762a0531-40da-4f1c-8ba2-acd278417e30@github.com>
References: <H3WNK3qa7r4NXwPkjzAo8kIgus6c9VedG5F64t0plH8=.762a0531-40da-4f1c-8ba2-acd278417e30@github.com>
Message-ID: <MWvnrjAmDwNqGuswCpWcmEWriVNXS6jdkkM4qr39198=.5bd1d73c-b578-4cba-85ff-0e4ca54066b7@github.com>

On Wed, 14 Jun 2023 09:30:49 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test fails when additional threads are created, as it compares thread lists from different sources and sees a mismatch.
> 
> It needs to tolerate some threads with certain names appearing, e.g. JVMCI and ForkJoin threads.  If there are extra threads in the thread ID list from the ThreadMBean, remove them from the thread count before comparing.
> 
> When it fails, additionally print the ids and names of threads that it got from the MBean.
> 
> I found the test quite confusing, the naming of thread counts, arrays of threads, and arrays of thread stacktraces from different sources, so have renamed some things.

The test assumes that it can find a set of steady-state threads running that does not change, but that is not the case. I don't find this test particularly useful in what it attempts to do. It would make more sense to have a set of test threads that it looks for via each method, and which it can control termination of and thus check that they disappear. Adding an allow-list of dynamically appearing threads seems somewhat fragile, but I guess we've really only seen two problematic scenarios:
- Running with virtual threads
- Running with JVMCI
so the fix "works".

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14465#pullrequestreview-1480552511

From cjplummer at openjdk.org  Thu Jun 15 03:11:58 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 15 Jun 2023 03:11:58 GMT
Subject: RFR: 8308499: Test
 vmTestbase/nsk/jdi/MethodExitRequest/addClassExclusionFilter/filter001/TestDescription.java
 failed: VMDisconnectedException
In-Reply-To: <NU8_ylDcVvFs_bs5W1MpqnSv8MgItBOlVdqgW7PpzI8=.7c2092d1-726c-499a-911b-f3c0101e5873@github.com>
References: <-0tDx5i1vrT6MQiPY9ZzRMVE6SibI7vqOJMjPuGywqU=.b25f2536-bfbf-4754-a56d-05f5a73fd3ba@github.com>
 <NU8_ylDcVvFs_bs5W1MpqnSv8MgItBOlVdqgW7PpzI8=.7c2092d1-726c-499a-911b-f3c0101e5873@github.com>
Message-ID: <BgK1VU8K_PL_9hAknXJI-ugF0hXxY-s3TeGjkfOnBqQ=.6e6e1803-1a4f-4717-a439-07e6589a4581@github.com>

On Wed, 14 Jun 2023 21:54:22 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The test gets overloaded with MethodExitEvents, causing them to queue up (in the JDI queue) and continue to be processed by the test after the debuggee exits. This results in a VMDisconnectedException when the test tries to do the following after getting an event:
>> 
>> `    String str = ((MethodExitEvent)event).location().declaringType().name(); `
>> 
>> The test is suppose to add filters to execlude events for all non-test classes, but it is only filtering `java.*` and `sun.*`. There are also a very large number of `jdk.*` events coming in, and this is what is causing the event backlog and the processing of events after disconnect. Filtering out `jdk.*` events reduces the total number of events to a few dozen, and the test passes.
>> 
>> More details can be found in the CR.
>> 
>> Testing in progress: tier5 svc testing, and also running the failing test on all platforms (both debug and product).
>
> test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addClassExclusionFilter/filter001.java line 77:
> 
>> 75:     private String classExclName1 = "java";
>> 76:     private String classExclName2 = "sun";
>> 77:     private String classExclName3 = "jdk";
> 
> The fix is reasonable. However,
> I think it would be better to use List<String> with List.of(...) and list.contains() to filter exclusions.

With 3 items it's borderline which approach to do. I find it easier to read the way it is now, especially checking the event classname, since it would require a loop that sets a flag that then has to be checked outside of the loop.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14480#discussion_r1230260039

From cjplummer at openjdk.org  Thu Jun 15 03:13:14 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 15 Jun 2023 03:13:14 GMT
Subject: RFR: 8303916: ThreadLists.java inconsistent results
In-Reply-To: <H3WNK3qa7r4NXwPkjzAo8kIgus6c9VedG5F64t0plH8=.762a0531-40da-4f1c-8ba2-acd278417e30@github.com>
References: <H3WNK3qa7r4NXwPkjzAo8kIgus6c9VedG5F64t0plH8=.762a0531-40da-4f1c-8ba2-acd278417e30@github.com>
Message-ID: <w8Tgcvpm1N6HTZBv3t9Xt2K95RKIqFxg0QIuTPN878U=.f72d922b-3c8e-4a6a-99f3-ae74e852bf28@github.com>

On Wed, 14 Jun 2023 09:30:49 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test fails when additional threads are created, as it compares thread lists from different sources and sees a mismatch.
> 
> It needs to tolerate some threads with certain names appearing, e.g. JVMCI and ForkJoin threads.  If there are extra threads in the thread ID list from the ThreadMBean, remove them from the thread count before comparing.
> 
> When it fails, additionally print the ids and names of threads that it got from the MBean.
> 
> I found the test quite confusing, the naming of thread counts, arrays of threads, and arrays of thread stacktraces from different sources, so have renamed some things.

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14465#pullrequestreview-1480590241

From lmesnik at openjdk.org  Thu Jun 15 03:20:57 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 15 Jun 2023 03:20:57 GMT
Subject: RFR: 8308499: Test
 vmTestbase/nsk/jdi/MethodExitRequest/addClassExclusionFilter/filter001/TestDescription.java
 failed: VMDisconnectedException
In-Reply-To: <-0tDx5i1vrT6MQiPY9ZzRMVE6SibI7vqOJMjPuGywqU=.b25f2536-bfbf-4754-a56d-05f5a73fd3ba@github.com>
References: <-0tDx5i1vrT6MQiPY9ZzRMVE6SibI7vqOJMjPuGywqU=.b25f2536-bfbf-4754-a56d-05f5a73fd3ba@github.com>
Message-ID: <hDFZdYs4_PsMq7n22aKIpiURFuHNHeG_uew0uXPblAo=.1b6398d2-7ccc-4ce3-b2cc-21a4828a339e@github.com>

On Wed, 14 Jun 2023 21:24:31 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The test gets overloaded with MethodExitEvents, causing them to queue up (in the JDI queue) and continue to be processed by the test after the debuggee exits. This results in a VMDisconnectedException when the test tries to do the following after getting an event:
> 
> `    String str = ((MethodExitEvent)event).location().declaringType().name(); `
> 
> The test is suppose to add filters to execlude events for all non-test classes, but it is only filtering `java.*` and `sun.*`. There are also a very large number of `jdk.*` events coming in, and this is what is causing the event backlog and the processing of events after disconnect. Filtering out `jdk.*` events reduces the total number of events to a few dozen, and the test passes.
> 
> More details can be found in the CR.
> 
> Testing in progress: tier5 svc testing, and also running the failing test on all platforms (both debug and product).

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14480#pullrequestreview-1480602395

From lmesnik at openjdk.org  Thu Jun 15 03:20:59 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 15 Jun 2023 03:20:59 GMT
Subject: RFR: 8308499: Test
 vmTestbase/nsk/jdi/MethodExitRequest/addClassExclusionFilter/filter001/TestDescription.java
 failed: VMDisconnectedException
In-Reply-To: <BgK1VU8K_PL_9hAknXJI-ugF0hXxY-s3TeGjkfOnBqQ=.6e6e1803-1a4f-4717-a439-07e6589a4581@github.com>
References: <-0tDx5i1vrT6MQiPY9ZzRMVE6SibI7vqOJMjPuGywqU=.b25f2536-bfbf-4754-a56d-05f5a73fd3ba@github.com>
 <NU8_ylDcVvFs_bs5W1MpqnSv8MgItBOlVdqgW7PpzI8=.7c2092d1-726c-499a-911b-f3c0101e5873@github.com>
 <BgK1VU8K_PL_9hAknXJI-ugF0hXxY-s3TeGjkfOnBqQ=.6e6e1803-1a4f-4717-a439-07e6589a4581@github.com>
Message-ID: <QrSCd5GMwFf9uPQqbeyPpdLmFkRi8zODIMSAqVqw_jc=.0958e4e2-3a62-4ce7-a271-608420cfb613@github.com>

On Wed, 14 Jun 2023 23:13:59 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> test/hotspot/jtreg/vmTestbase/nsk/jdi/MethodExitRequest/addClassExclusionFilter/filter001.java line 77:
>> 
>>> 75:     private String classExclName1 = "java";
>>> 76:     private String classExclName2 = "sun";
>>> 77:     private String classExclName3 = "jdk";
>> 
>> The fix is reasonable. However,
>> I think it would be better to use List<String> with List.of(...) and list.contains() to filter exclusions.
>
> With 3 items it's borderline which approach to do. I find it easier to read the way it is now, especially checking the event classname, since it would require a loop that sets a flag that then has to be checked outside of the loop.

If you think it is easier, then fine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14480#discussion_r1230374885

From lmesnik at openjdk.org  Thu Jun 15 03:47:56 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 15 Jun 2023 03:47:56 GMT
Subject: RFR: 8303916: ThreadLists.java inconsistent results
In-Reply-To: <H3WNK3qa7r4NXwPkjzAo8kIgus6c9VedG5F64t0plH8=.762a0531-40da-4f1c-8ba2-acd278417e30@github.com>
References: <H3WNK3qa7r4NXwPkjzAo8kIgus6c9VedG5F64t0plH8=.762a0531-40da-4f1c-8ba2-acd278417e30@github.com>
Message-ID: <G6xZgao0idxFUCbGuHh_6Uj-lPo0g756MQH1aSZdkHg=.744bdba3-1f47-478e-81d7-73144558e6c7@github.com>

On Wed, 14 Jun 2023 09:30:49 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test fails when additional threads are created, as it compares thread lists from different sources and sees a mismatch.
> 
> It needs to tolerate some threads with certain names appearing, e.g. JVMCI and ForkJoin threads.  If there are extra threads in the thread ID list from the ThreadMBean, remove them from the thread count before comparing.
> 
> When it fails, additionally print the ids and names of threads that it got from the MBean.
> 
> I found the test quite confusing, the naming of thread counts, arrays of threads, and arrays of thread stacktraces from different sources, so have renamed some things.

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14465#pullrequestreview-1480621939

From alanb at openjdk.org  Thu Jun 15 06:10:57 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 15 Jun 2023 06:10:57 GMT
Subject: RFR: 8303916: ThreadLists.java inconsistent results
In-Reply-To: <H3WNK3qa7r4NXwPkjzAo8kIgus6c9VedG5F64t0plH8=.762a0531-40da-4f1c-8ba2-acd278417e30@github.com>
References: <H3WNK3qa7r4NXwPkjzAo8kIgus6c9VedG5F64t0plH8=.762a0531-40da-4f1c-8ba2-acd278417e30@github.com>
Message-ID: <1RknjI-IroLrZ1tIU7yPHcvCZ5SHXwLwXBREWcDVcZQ=.c072d8b1-0230-43be-830f-7c5b2aa60ae4@github.com>

On Wed, 14 Jun 2023 09:30:49 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test fails when additional threads are created, as it compares thread lists from different sources and sees a mismatch.
> 
> It needs to tolerate some threads with certain names appearing, e.g. JVMCI and ForkJoin threads.  If there are extra threads in the thread ID list from the ThreadMBean, remove them from the thread count before comparing.
> 
> When it fails, additionally print the ids and names of threads that it got from the MBean.
> 
> I found the test quite confusing, the naming of thread counts, arrays of threads, and arrays of thread stacktraces from different sources, so have renamed some things.

I agree with David and would be concerned this test will be whack-a-mole to deal with other cases. It would be a lot simpler to have a test that creates a number of threads, then uses Thread.getAllThreadStacks + ThreadMXBean.getAllThreadIds to that the expected list of threads are included. If the current thread is not a virtual thread then it can check that it is included too. If you really want to check that both methods return the same list of threads then I think it will need to loop + backoff when the threads aren't the same.

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

PR Comment: https://git.openjdk.org/jdk/pull/14465#issuecomment-1592424397

From alanb at openjdk.org  Thu Jun 15 07:16:59 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 15 Jun 2023 07:16:59 GMT
Subject: RFR: 8309408: Thread.sleep cleanup
In-Reply-To: <MYT2jZZfh3gpAf3ovevvUHF4b1UhCnZfHdrJ7bmuBxk=.d0671acf-8f9d-4913-903a-8f5dde98a981@github.com>
References: <aQgYdV9yETAis_U44TCaI5C5MTR4DMMD-5Li28_cbvc=.6d65e000-4b13-4f27-a7d8-e6854e99337f@github.com>
 <Nu86at67VHbLwludO5_y6eZKQ6qPa4LtXQj15OKF0vo=.509fbe94-1573-4c26-90e1-b4dd7ce1b780@github.com>
 <MYT2jZZfh3gpAf3ovevvUHF4b1UhCnZfHdrJ7bmuBxk=.d0671acf-8f9d-4913-903a-8f5dde98a981@github.com>
Message-ID: <y4FlQ6RdSd_MkhySJ7vu_8ISbFgzHOXGrnfElMBqo0Q=.8b6911c7-eb9f-4192-bd7e-aa71392dd879@github.com>

On Mon, 5 Jun 2023 19:44:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > I think we need to delay this until [JDK-8309361](https://bugs.openjdk.org/browse/JDK-8309361) is resolved, in case we would like to revert [JDK-8305092](https://bugs.openjdk.org/browse/JDK-8305092).
> 
> Okay, I won't integrate this until we see what the issue is. That said, if the sub-mills support needs to be reverted then I think we should keep the interface as nanos on the boundary between the VM and the libraries. The reason is that it's mostly nanos at the Java level now, meaning 2 out of the 3 sleep methods support sub-mills, and the virtual thread sleep and the JFR event are in nanos too.

JDK-8309361 doesn't have a conclusion yet but doesn't look like it's a JDK implementation issue or heading toward removing the support for sub-mills precision.  So I think we should integrate this cleanup and get it out of the way. Even if there are changes then I think it's better for the precision at the interface to be nanos.

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

PR Comment: https://git.openjdk.org/jdk/pull/14303#issuecomment-1592491455

From kevinw at openjdk.org  Thu Jun 15 08:31:56 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 15 Jun 2023 08:31:56 GMT
Subject: RFR: 8308499: Test
 vmTestbase/nsk/jdi/MethodExitRequest/addClassExclusionFilter/filter001/TestDescription.java
 failed: VMDisconnectedException
In-Reply-To: <-0tDx5i1vrT6MQiPY9ZzRMVE6SibI7vqOJMjPuGywqU=.b25f2536-bfbf-4754-a56d-05f5a73fd3ba@github.com>
References: <-0tDx5i1vrT6MQiPY9ZzRMVE6SibI7vqOJMjPuGywqU=.b25f2536-bfbf-4754-a56d-05f5a73fd3ba@github.com>
Message-ID: <YHAZvlGQZNtnLfCVVXzsQFnFpYqwTv0-PlOzthU16XY=.fc8c4c22-622a-4411-86e7-4b62cae7fa0e@github.com>

On Wed, 14 Jun 2023 21:24:31 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The test gets overloaded with MethodExitEvents, causing them to queue up (in the JDI queue) and continue to be processed by the test after the debuggee exits. This results in a VMDisconnectedException when the test tries to do the following after getting an event:
> 
> `    String str = ((MethodExitEvent)event).location().declaringType().name(); `
> 
> The test is suppose to add filters to execlude events for all non-test classes, but it is only filtering `java.*` and `sun.*`. There are also a very large number of `jdk.*` events coming in, and this is what is causing the event backlog and the processing of events after disconnect. Filtering out `jdk.*` events reduces the total number of events to a few dozen, and the test passes.
> 
> More details can be found in the CR.
> 
> Testing in progress: tier5 svc testing, and also running the failing test on all platforms (both debug and product).

Marked as reviewed by kevinw (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/14480#pullrequestreview-1480997502

From kevinw at openjdk.org  Thu Jun 15 09:20:01 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 15 Jun 2023 09:20:01 GMT
Subject: RFR: 8303916: ThreadLists.java inconsistent results
In-Reply-To: <H3WNK3qa7r4NXwPkjzAo8kIgus6c9VedG5F64t0plH8=.762a0531-40da-4f1c-8ba2-acd278417e30@github.com>
References: <H3WNK3qa7r4NXwPkjzAo8kIgus6c9VedG5F64t0plH8=.762a0531-40da-4f1c-8ba2-acd278417e30@github.com>
Message-ID: <YWEgolCKkAFKry4d_j0ww7-uq9CFnxU4wR7ZIPgReAk=.59568ea5-da11-4471-a1ba-78d7a0d43adb@github.com>

On Wed, 14 Jun 2023 09:30:49 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test fails when additional threads are created, as it compares thread lists from different sources and sees a mismatch.
> 
> It needs to tolerate some threads with certain names appearing, e.g. JVMCI and ForkJoin threads.  If there are extra threads in the thread ID list from the ThreadMBean, remove them from the thread count before comparing.
> 
> When it fails, additionally print the ids and names of threads that it got from the MBean.
> 
> I found the test quite confusing, the naming of thread counts, arrays of threads, and arrays of thread stacktraces from different sources, so have renamed some things.

Thanks for the comments and reviews.

I did look at the history and this test exists because of previous confusion about thread groups, where the top thread group and the MXBean thread lists could be different.  So if this test creates new threads and checks they are in both lists, it loses the original purpose as I read it.

I'm not saying it's a great test.  But it successfully monitored that problem since 2004, and lasted surprisingly well even before being moved to an "othervm" !
 
If there's any mole-whacking, I think the new logging should make it easy to see the name of the mole, and if it's a thread that's expected to appear possibly between the observations, then it can be added to the list.  It is just those two new things, JVMCI and ForkJoinPool, which are known to fool it so far.  We should make this change and watch for moles appearing, or indeed disappearing.

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

PR Comment: https://git.openjdk.org/jdk/pull/14465#issuecomment-1592680861

From alanb at openjdk.org  Thu Jun 15 10:30:34 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 15 Jun 2023 10:30:34 GMT
Subject: RFR: 8309408: Thread.sleep cleanup [v2]
In-Reply-To: <aQgYdV9yETAis_U44TCaI5C5MTR4DMMD-5Li28_cbvc=.6d65e000-4b13-4f27-a7d8-e6854e99337f@github.com>
References: <aQgYdV9yETAis_U44TCaI5C5MTR4DMMD-5Li28_cbvc=.6d65e000-4b13-4f27-a7d8-e6854e99337f@github.com>
Message-ID: <2AS77yfkB1xFobWQFaRarRplDgyT_VobybDkP3jdzxU=.031e3d04-df14-4c5f-8404-5a45b96d35f4@github.com>

> Thread.sleep has had quite a bit of churn recently to support virtual threads, add sleep(Duration), a JFR event, and the change the underlying implementation to support sub-millis precision. I think the changes have settled down now so we can do some small cleanups that came up in PR discussions. The cleanups were kicked down the road as it requires tracking down faraway tests that depend on the stack depth and the names of internal methods. The two cleanups proposed here are:
> 
> 1.  Add a private sleepNanos method that creates/commits the JFR event around the sleep, this avoids duplicate code in the 3 sleep methods.
> 2.  Rename JVM_Sleep to JVM_SleepNanos to make it clear that it takes the sleep time in nanoseconds, esp. when Thread.sleep's parameter is milliseconds.

Alan Bateman 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 four additional commits since the last revision:

 - Merge
 - Merge
 - Add beforeSleep/afterSleep to list of expected methods
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14303/files
  - new: https://git.openjdk.org/jdk/pull/14303/files/ae6b531f..593f2a53

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14303&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14303&range=00-01

  Stats: 55233 lines in 963 files changed: 39216 ins; 12904 del; 3113 mod
  Patch: https://git.openjdk.org/jdk/pull/14303.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14303/head:pull/14303

PR: https://git.openjdk.org/jdk/pull/14303

From duke at openjdk.org  Thu Jun 15 15:12:59 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Thu, 15 Jun 2023 15:12:59 GMT
Subject: RFR: 8309979: BootstrapMethods attribute is missing in class files
 recreated by SA
Message-ID: <nSooA6CtKm8LsaxzYdqJ6mtVV0os-kT5F2xNvYI4lJo=.c27bd28e-88d3-4bcb-ac3d-9036140eeff0@github.com>

Please review this PR that extends SA to write BootstrapMethods attribute when dumping the class files.

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

Commit messages:
 - 8309979: BootstrapMethods attribute is missing in class files recreated by SA

Changes: https://git.openjdk.org/jdk/pull/14495/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14495&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309979
  Stats: 80 lines in 3 files changed: 72 ins; 2 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/14495.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14495/head:pull/14495

PR: https://git.openjdk.org/jdk/pull/14495

From cjplummer at openjdk.org  Thu Jun 15 18:10:28 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 15 Jun 2023 18:10:28 GMT
Subject: RFR: 8308499: Test
 vmTestbase/nsk/jdi/MethodExitRequest/addClassExclusionFilter/filter001/TestDescription.java
 failed: VMDisconnectedException
In-Reply-To: <-0tDx5i1vrT6MQiPY9ZzRMVE6SibI7vqOJMjPuGywqU=.b25f2536-bfbf-4754-a56d-05f5a73fd3ba@github.com>
References: <-0tDx5i1vrT6MQiPY9ZzRMVE6SibI7vqOJMjPuGywqU=.b25f2536-bfbf-4754-a56d-05f5a73fd3ba@github.com>
Message-ID: <Z0fcp-XsVDfEDdEU4hFpdguxTOF9TZDqzDaXouY9rY4=.ea7bc2b9-d7ab-4200-8f17-28440bac2bfa@github.com>

On Wed, 14 Jun 2023 21:24:31 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The test gets overloaded with MethodExitEvents, causing them to queue up (in the JDI queue) and continue to be processed by the test after the debuggee exits. This results in a VMDisconnectedException when the test tries to do the following after getting an event:
> 
> `    String str = ((MethodExitEvent)event).location().declaringType().name(); `
> 
> The test is suppose to add filters to execlude events for all non-test classes, but it is only filtering `java.*` and `sun.*`. There are also a very large number of `jdk.*` events coming in, and this is what is causing the event backlog and the processing of events after disconnect. Filtering out `jdk.*` events reduces the total number of events to a few dozen, and the test passes.
> 
> More details can be found in the CR.
> 
> Testing in progress: tier5 svc testing, and also running the failing test on all platforms (both debug and product).

Thanks for the reviews Leonid and Kevin!

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

PR Comment: https://git.openjdk.org/jdk/pull/14480#issuecomment-1593512819

From cjplummer at openjdk.org  Thu Jun 15 18:24:58 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 15 Jun 2023 18:24:58 GMT
Subject: RFR: 8309979: BootstrapMethods attribute is missing in class files
 recreated by SA
In-Reply-To: <nSooA6CtKm8LsaxzYdqJ6mtVV0os-kT5F2xNvYI4lJo=.c27bd28e-88d3-4bcb-ac3d-9036140eeff0@github.com>
References: <nSooA6CtKm8LsaxzYdqJ6mtVV0os-kT5F2xNvYI4lJo=.c27bd28e-88d3-4bcb-ac3d-9036140eeff0@github.com>
Message-ID: <Pvrh6jAZIjP9f9Dhtm-uK5VioU3IasFXcihqVY7qoBU=.b71aacfc-5cd6-4571-9bda-00ad5bf9d99a@github.com>

On Thu, 15 Jun 2023 15:06:54 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

> Please review this PR that extends SA to write BootstrapMethods attribute when dumping the class files.

Changes requested by cjplummer (Reviewer).

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPool.java line 498:

> 496:     U2Array operands = getOperands();
> 497:     if (operands == null)  return null;  // safety first
> 498:     int basePos = getOperandOffsetAt(bsmIndex);

Maybe you should pass `operands` into `getOperandOffsetAt()` so it does not need to be fetched again.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java line 694:

> 692:         if (bsmCount != 0)
> 693:             classAttributeCount++;
> 694: 

Please use curly braces here.

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

PR Review: https://git.openjdk.org/jdk/pull/14495#pullrequestreview-1482155574
PR Review Comment: https://git.openjdk.org/jdk/pull/14495#discussion_r1231384753
PR Review Comment: https://git.openjdk.org/jdk/pull/14495#discussion_r1231388162

From cjplummer at openjdk.org  Thu Jun 15 19:15:18 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 15 Jun 2023 19:15:18 GMT
Subject: Integrated: 8308499: Test
 vmTestbase/nsk/jdi/MethodExitRequest/addClassExclusionFilter/filter001/TestDescription.java
 failed: VMDisconnectedException
In-Reply-To: <-0tDx5i1vrT6MQiPY9ZzRMVE6SibI7vqOJMjPuGywqU=.b25f2536-bfbf-4754-a56d-05f5a73fd3ba@github.com>
References: <-0tDx5i1vrT6MQiPY9ZzRMVE6SibI7vqOJMjPuGywqU=.b25f2536-bfbf-4754-a56d-05f5a73fd3ba@github.com>
Message-ID: <5PGDZPbGLLIsibmxNnYQZ4K3UdDNL-abKtWvwNd4Foc=.27e6266f-0536-49bc-9f2b-99e75304692a@github.com>

On Wed, 14 Jun 2023 21:24:31 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The test gets overloaded with MethodExitEvents, causing them to queue up (in the JDI queue) and continue to be processed by the test after the debuggee exits. This results in a VMDisconnectedException when the test tries to do the following after getting an event:
> 
> `    String str = ((MethodExitEvent)event).location().declaringType().name(); `
> 
> The test is suppose to add filters to execlude events for all non-test classes, but it is only filtering `java.*` and `sun.*`. There are also a very large number of `jdk.*` events coming in, and this is what is causing the event backlog and the processing of events after disconnect. Filtering out `jdk.*` events reduces the total number of events to a few dozen, and the test passes.
> 
> More details can be found in the CR.
> 
> Testing in progress: tier5 svc testing, and also running the failing test on all platforms (both debug and product).

This pull request has now been integrated.

Changeset: 79ff72a7
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/79ff72a7762deb6010b57e5ac0ccede3d035ab4c
Stats:     7 lines in 1 file changed: 5 ins; 0 del; 2 mod

8308499: Test vmTestbase/nsk/jdi/MethodExitRequest/addClassExclusionFilter/filter001/TestDescription.java failed: VMDisconnectedException

Reviewed-by: lmesnik, kevinw

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

PR: https://git.openjdk.org/jdk/pull/14480

From jlu at openjdk.org  Thu Jun 15 19:45:52 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 15 Jun 2023 19:45:52 GMT
Subject: Integrated: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
Message-ID: <wHemDob1LcBUGrp94CGVymYmeivv2G9ccgjfngb7m84=.a4d37dbb-54fd-4920-8734-dd2080aeaf32@github.com>

On Mon, 12 Jun 2023 22:00:01 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

This pull request has now been integrated.

Changeset: 81bfd789
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/81bfd78901ff540ad0355a466cfad097e701028a
Stats:     460 lines in 50 files changed: 279 ins; 48 del; 133 mod

8309632: JDK 21 RDP1 L10n resource files update

Reviewed-by: naoto

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

PR: https://git.openjdk.org/jdk/pull/14430

From kcr at openjdk.org  Thu Jun 15 20:05:30 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 15 Jun 2023 20:05:30 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
Message-ID: <lk-HQVh3RGdNHbBiHftYiYZQzEq5Hp6CCtCXPjSbAPs=.ae8c0707-7daf-4142-8147-1ea24323364a@github.com>

On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

I was 

> @kevinrushforth Thanks for the reminder, will make the change in ML first.

Thanks. And I see you made this PR Draft, which is a good idea. Once the mainline PR is integrated, you can change the title of this PR to `Backport NNNNNNNNNNN`, where `NNNNNNNNNNN` is the 40 character commit hash of the jdk master commit. Then Skara will note this as a Backport, and also note whether it is a clean backport.

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

PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1588176435

From duke at openjdk.org  Thu Jun 15 20:05:31 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Thu, 15 Jun 2023 20:05:31 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
Message-ID: <j-x2Vg89HAUcCaDz51mqofqhoX932hkfEGlaF-FvKIo=.8473b365-250a-47c3-b052-9d78947374de@github.com>

On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar_de.properties line 115:

> 113: main.help.opt.main.validate=\      --validate             Validiert den Inhalt des JAR-Archivs. Diese Option\n                             validiert, dass die von einem Multi-Release-JAR-Archiv\n                             exportierte API \u00FCber die verschiedenen Releaseversionen\n                             hinweg konsistent ist.
> 114: main.help.opt.any=\ In jedem Modus g\u00FCltige Vorgangsmodifikatoren:\n\n  -C DIR                     Zum angegebenen Verzeichnis wechseln und die folgende\n                             Datei aufnehmen
> 115: main.help.opt.any.file=\  -f, --file=FILE            Der Name der Archivdatei. Wenn Sie dies lauslassen, wird entweder stdin oder\n                             stdout verwendet, je nach Vorgang\n      --release VERSION      Speichert alle der folgenden Dateien in einem versionierten Verzeichnis\n                             der JAR-Datei (d.h. META-INF/versions/VERSION/)

(Review comment moved to mainline PR)

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

PR Review Comment: https://git.openjdk.org/jdk21/pull/11#discussion_r1227287139

From duke at openjdk.org  Thu Jun 15 20:24:39 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Thu, 15 Jun 2023 20:24:39 GMT
Subject: RFR: 8309979: BootstrapMethods attribute is missing in class files
 recreated by SA [v2]
In-Reply-To: <nSooA6CtKm8LsaxzYdqJ6mtVV0os-kT5F2xNvYI4lJo=.c27bd28e-88d3-4bcb-ac3d-9036140eeff0@github.com>
References: <nSooA6CtKm8LsaxzYdqJ6mtVV0os-kT5F2xNvYI4lJo=.c27bd28e-88d3-4bcb-ac3d-9036140eeff0@github.com>
Message-ID: <i3PjGx_wbQ63SlwcWL5eBr28sDUb1_dPQ8Q0P3Qgzds=.5f11a8e5-714c-45c0-87e6-e612bb50b28b@github.com>

> Please review this PR that extends SA to write BootstrapMethods attribute when dumping the class files.

Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments by plummercj
  
  Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14495/files
  - new: https://git.openjdk.org/jdk/pull/14495/files/a2755e4e..3a7ad373

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14495&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14495&range=00-01

  Stats: 10 lines in 2 files changed: 1 ins; 4 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14495.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14495/head:pull/14495

PR: https://git.openjdk.org/jdk/pull/14495

From duke at openjdk.org  Thu Jun 15 20:24:42 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Thu, 15 Jun 2023 20:24:42 GMT
Subject: RFR: 8309979: BootstrapMethods attribute is missing in class files
 recreated by SA [v2]
In-Reply-To: <Pvrh6jAZIjP9f9Dhtm-uK5VioU3IasFXcihqVY7qoBU=.b71aacfc-5cd6-4571-9bda-00ad5bf9d99a@github.com>
References: <nSooA6CtKm8LsaxzYdqJ6mtVV0os-kT5F2xNvYI4lJo=.c27bd28e-88d3-4bcb-ac3d-9036140eeff0@github.com>
 <Pvrh6jAZIjP9f9Dhtm-uK5VioU3IasFXcihqVY7qoBU=.b71aacfc-5cd6-4571-9bda-00ad5bf9d99a@github.com>
Message-ID: <Dkhm42K1cc_2yMSZHee8otdI3V3NEzW2p2GfsdjyiH0=.ad389864-344b-4a36-b419-a933cc7e3468@github.com>

On Thu, 15 Jun 2023 18:15:41 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments by plummercj
>>   
>>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPool.java line 498:
> 
>> 496:     U2Array operands = getOperands();
>> 497:     if (operands == null)  return null;  // safety first
>> 498:     int basePos = getOperandOffsetAt(bsmIndex);
> 
> Maybe you should pass `operands` into `getOperandOffsetAt()` so it does not need to be fetched again.

Done.

> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java line 694:
> 
>> 692:         if (bsmCount != 0)
>> 693:             classAttributeCount++;
>> 694: 
> 
> Please use curly braces here.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14495#discussion_r1231495232
PR Review Comment: https://git.openjdk.org/jdk/pull/14495#discussion_r1231495480

From cjplummer at openjdk.org  Thu Jun 15 20:31:02 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 15 Jun 2023 20:31:02 GMT
Subject: RFR: 8309979: BootstrapMethods attribute is missing in class files
 recreated by SA [v2]
In-Reply-To: <i3PjGx_wbQ63SlwcWL5eBr28sDUb1_dPQ8Q0P3Qgzds=.5f11a8e5-714c-45c0-87e6-e612bb50b28b@github.com>
References: <nSooA6CtKm8LsaxzYdqJ6mtVV0os-kT5F2xNvYI4lJo=.c27bd28e-88d3-4bcb-ac3d-9036140eeff0@github.com>
 <i3PjGx_wbQ63SlwcWL5eBr28sDUb1_dPQ8Q0P3Qgzds=.5f11a8e5-714c-45c0-87e6-e612bb50b28b@github.com>
Message-ID: <kDsZ8b6Fd_OCSBm4Jq7d3hIyIizBQoY1TxwvqwE_CJU=.dfa70219-37ca-423e-a5b8-69592020c8e4@github.com>

On Thu, 15 Jun 2023 20:24:39 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> Please review this PR that extends SA to write BootstrapMethods attribute when dumping the class files.
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments by plummercj
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14495#pullrequestreview-1482338739

From cjplummer at openjdk.org  Thu Jun 15 20:58:01 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 15 Jun 2023 20:58:01 GMT
Subject: RFR: 8309979: BootstrapMethods attribute is missing in class files
 recreated by SA [v2]
In-Reply-To: <i3PjGx_wbQ63SlwcWL5eBr28sDUb1_dPQ8Q0P3Qgzds=.5f11a8e5-714c-45c0-87e6-e612bb50b28b@github.com>
References: <nSooA6CtKm8LsaxzYdqJ6mtVV0os-kT5F2xNvYI4lJo=.c27bd28e-88d3-4bcb-ac3d-9036140eeff0@github.com>
 <i3PjGx_wbQ63SlwcWL5eBr28sDUb1_dPQ8Q0P3Qgzds=.5f11a8e5-714c-45c0-87e6-e612bb50b28b@github.com>
Message-ID: <GmG4a-F-XeiPsTTYHRflHqT6k9Pj4d4S4hAcmkd_h3k=.090d6b2c-0084-4b3c-b71a-354d049f4618@github.com>

On Thu, 15 Jun 2023 20:24:39 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> Please review this PR that extends SA to write BootstrapMethods attribute when dumping the class files.
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments by plummercj
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

Can you tell me what testing you've done? Would be best to call that out in the PR description.

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

PR Comment: https://git.openjdk.org/jdk/pull/14495#issuecomment-1593712137

From kcr at openjdk.org  Thu Jun 15 21:09:09 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 15 Jun 2023 21:09:09 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
Message-ID: <m18QxOywT0xCREEM4OCHxSF8AbqQwi7YYfqXL0eFP0M=.e52d4740-1d7b-43ce-8734-a2382418290c@github.com>

On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

Is the patch expected to be the same as in jdk mainline? I see some differences between the two patches (which is why Skara didn't mark it as "clean")

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

PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1593724465

From jlu at openjdk.org  Thu Jun 15 21:13:00 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 15 Jun 2023 21:13:00 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <m18QxOywT0xCREEM4OCHxSF8AbqQwi7YYfqXL0eFP0M=.e52d4740-1d7b-43ce-8734-a2382418290c@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
 <m18QxOywT0xCREEM4OCHxSF8AbqQwi7YYfqXL0eFP0M=.e52d4740-1d7b-43ce-8734-a2382418290c@github.com>
Message-ID: <8055MPxK8nGDItLuewscD0HhRwu4yJHWRoWg1H_SEu4=.7a2b5b3b-422c-4d32-8b68-d856a6ac8c05@github.com>

On Thu, 15 Jun 2023 21:06:32 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Is the patch expected to be the same as in jdk mainline? I see some differences between the two patches (which is why Skara didn't mark it as "clean")

Hi Kevin, yes it is. I still need to grab the changes from mainline and include them in this PR.

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

PR Comment: https://git.openjdk.org/jdk21/pull/11#issuecomment-1593728784

From duke at openjdk.org  Thu Jun 15 22:58:59 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Thu, 15 Jun 2023 22:58:59 GMT
Subject: RFR: 8309979: BootstrapMethods attribute is missing in class files
 recreated by SA [v2]
In-Reply-To: <GmG4a-F-XeiPsTTYHRflHqT6k9Pj4d4S4hAcmkd_h3k=.090d6b2c-0084-4b3c-b71a-354d049f4618@github.com>
References: <nSooA6CtKm8LsaxzYdqJ6mtVV0os-kT5F2xNvYI4lJo=.c27bd28e-88d3-4bcb-ac3d-9036140eeff0@github.com>
 <i3PjGx_wbQ63SlwcWL5eBr28sDUb1_dPQ8Q0P3Qgzds=.5f11a8e5-714c-45c0-87e6-e612bb50b28b@github.com>
 <GmG4a-F-XeiPsTTYHRflHqT6k9Pj4d4S4hAcmkd_h3k=.090d6b2c-0084-4b3c-b71a-354d049f4618@github.com>
Message-ID: <ldx4S69WHYEKayxXmvcPV1LkG5XRUd3AJh-CniQHte4=.50f23756-a109-4ee5-b52c-29fa9630c896@github.com>

On Thu, 15 Jun 2023 20:55:12 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Can you tell me what testing you've done? Would be best to call that out in the PR description.

Edited the description to add a comment about the testing. Hope this helps.

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

PR Comment: https://git.openjdk.org/jdk/pull/14495#issuecomment-1593820565

From cjplummer at openjdk.org  Thu Jun 15 23:24:10 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 15 Jun 2023 23:24:10 GMT
Subject: RFR: 8309979: BootstrapMethods attribute is missing in class files
 recreated by SA [v2]
In-Reply-To: <i3PjGx_wbQ63SlwcWL5eBr28sDUb1_dPQ8Q0P3Qgzds=.5f11a8e5-714c-45c0-87e6-e612bb50b28b@github.com>
References: <nSooA6CtKm8LsaxzYdqJ6mtVV0os-kT5F2xNvYI4lJo=.c27bd28e-88d3-4bcb-ac3d-9036140eeff0@github.com>
 <i3PjGx_wbQ63SlwcWL5eBr28sDUb1_dPQ8Q0P3Qgzds=.5f11a8e5-714c-45c0-87e6-e612bb50b28b@github.com>
Message-ID: <u1oTH8KS-kJJxLyJCylgYxzQwxLmWlzH7-SqD_VNeXY=.2b763b0b-b513-49e5-b79f-dc2874973d15@github.com>

On Thu, 15 Jun 2023 20:24:39 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> Please review this PR that extends SA to write BootstrapMethods attribute when dumping the class files.
>> 
>> Tested it by dumping the class file for java/lang/String and comparing the BootstrapMethods attribute shown by javap for the original and the dumped class.
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments by plummercj
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

Can you run the tests in `test/hotspot/jtreg/serviceability/sa` and `test/jdk/sun/tools/jhsdb/`? thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/14495#issuecomment-1593838252

From jlu at openjdk.org  Fri Jun 16 04:39:42 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 16 Jun 2023 04:39:42 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
Message-ID: <m9PrVsggrFrkz3bYRVKXRBYTLpdjJjJgcqqAcw5p0UI=.5c786c31-5a91-4948-a415-4233a287a92c@github.com>

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

Justin Lu has updated the pull request incrementally with five additional commits since the last revision:

 - Review: correct previous commit, remove ? as well
 - Review: Remove ?? from 'javac.opt.Xlint.desc.output-file-clash' for zh_CN
 - Review: Use old 'err.crash' zh_CN value
 - Review: use Naoto's recommended ja values
 - Revert 'main.help.opt.any.file' value for _de

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

Changes:
  - all: https://git.openjdk.org/jdk21/pull/11/files
  - new: https://git.openjdk.org/jdk21/pull/11/files/13b8b309..a2e52373

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk21&pr=11&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk21&pr=11&range=00-01

  Stats: 8 lines in 5 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk21/pull/11.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/11/head:pull/11

PR: https://git.openjdk.org/jdk21/pull/11

From sspitsyn at openjdk.org  Fri Jun 16 05:52:59 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 16 Jun 2023 05:52:59 GMT
Subject: RFR: 8309663: test fails
 "assert(check_alignment(result)) failed: address not aligned:
 0x00000008baadbabe"
In-Reply-To: <fqPCs7pEUNY9ODLKOspB5buuBWtDPfKmouI8p05KBKw=.16dec9bd-ca79-41ef-808f-4967073151d2@github.com>
References: <fqPCs7pEUNY9ODLKOspB5buuBWtDPfKmouI8p05KBKw=.16dec9bd-ca79-41ef-808f-4967073151d2@github.com>
Message-ID: <iqmW_fIFTeMoYg62tAA3pLT4fM1Aq3boeGyxEIodKoQ=.3aa24da9-b5db-4c32-952c-d098dcf59344@github.com>

On Wed, 14 Jun 2023 01:02:09 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> If virtual thread has frames in stackChunks, need to apply load barriers before processing nmethods (javaVFrame::locals() and javaVFrame::expressions() do it internally)
> 
> Testing: tier1-tier5;
> 400 runs of VThreadStackRefTest.java test on linux-x64 and linux-x64-debug with "-XX:+UseZGC -Xcomp -XX:-TieredCompilation"

Looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14460#pullrequestreview-1482760969

From sspitsyn at openjdk.org  Fri Jun 16 05:53:02 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 16 Jun 2023 05:53:02 GMT
Subject: RFR: 8309663: test fails
 "assert(check_alignment(result)) failed: address not aligned:
 0x00000008baadbabe"
In-Reply-To: <E2U5bfawmMjCgzqe9pnzCBsL32YGRPcJUQ-ECswmLiY=.3cd140e7-1118-4485-9b32-822fa0af8f33@github.com>
References: <fqPCs7pEUNY9ODLKOspB5buuBWtDPfKmouI8p05KBKw=.16dec9bd-ca79-41ef-808f-4967073151d2@github.com>
 <Q5PaUjdpGBvTADcC1vItvofC1VMICsdSYvoVsTslqzA=.e03a47a5-a331-4d13-b622-f203e3430404@github.com>
 <E2U5bfawmMjCgzqe9pnzCBsL32YGRPcJUQ-ECswmLiY=.3cd140e7-1118-4485-9b32-822fa0af8f33@github.com>
Message-ID: <KmgtTOPbRb1Tpw6nDG576zl6_JRsdh_sk_WwmSS61AU=.9ed092da-0c5a-4596-a4fb-886b708d7e60@github.com>

On Wed, 14 Jun 2023 19:28:23 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiTagMap.cpp line 2325:
>> 
>>> 2323:         // Need to apply load barriers for unmounted vthreads.
>>> 2324:         nmethod* nm = jvf->cb()->as_nmethod();
>>> 2325:         nm->run_nmethod_entry_barrier();
>> 
>> This looks good in general.
>> However, I'm looking at the `stackChunkOopDesc::do_barriers0()` implementation and wonder if a similar trick is needed for interpreter frames (to support `Class Redefinition`):
>> 
>> template <stackChunkOopDesc::BarrierType barrier, ChunkFrames frame_kind, typename RegisterMapT>
>> void stackChunkOopDesc::do_barriers0(const StackChunkFrameStream<frame_kind>& f, const RegisterMapT* map) {
>>   // We need to invoke the write barriers so as not to miss oops in old chunks that haven't yet been concurrently scanned
>>   assert (!f.is_done(), "");
>> 
>>   if (f.is_interpreted()) {
>>     Method* m = f.to_frame().interpreter_frame_method();
>>     // Class redefinition support
>>     m->record_gc_epoch();
>>   } else if (f.is_compiled()) {
>>     nmethod* nm = f.cb()->as_nmethod();
>>     // The entry barrier takes care of having the right synchronization
>>     // when keeping the nmethod alive during concurrent execution.
>>     nm->run_nmethod_entry_barrier();
>>     // There is no need to mark the Method, as class redefinition will walk the
>>     // CodeCache, noting their Methods
>>   }
>>   . . .
>
>> This looks good in general. However, I'm looking at the `stackChunkOopDesc::do_barriers0()` implementation and wonder if a similar trick is needed for interpreter frames (to support `Class Redefinition`):
>> 
> 
> This code collects references from thread stack, I don't see how class redefinition can affect them

Thanks. I agree with it.
The stackChunkOopDesc implementation needs it as it does some stack chunk updates.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14460#discussion_r1231803017

From alanb at openjdk.org  Fri Jun 16 07:29:27 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 Jun 2023 07:29:27 GMT
Subject: Integrated: 8309408: Thread.sleep cleanup
In-Reply-To: <aQgYdV9yETAis_U44TCaI5C5MTR4DMMD-5Li28_cbvc=.6d65e000-4b13-4f27-a7d8-e6854e99337f@github.com>
References: <aQgYdV9yETAis_U44TCaI5C5MTR4DMMD-5Li28_cbvc=.6d65e000-4b13-4f27-a7d8-e6854e99337f@github.com>
Message-ID: <qrmFnrqf_ZxNB1Qaq06FWZBdlSCIlMBWJCqTaEm7Gjs=.b955e644-4b95-4b94-85a3-92194d1d23eb@github.com>

On Sun, 4 Jun 2023 11:28:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thread.sleep has had quite a bit of churn recently to support virtual threads, add sleep(Duration), a JFR event, and the change the underlying implementation to support sub-millis precision. I think the changes have settled down now so we can do some small cleanups that came up in PR discussions. The cleanups were kicked down the road as it requires tracking down faraway tests that depend on the stack depth and the names of internal methods. The two cleanups proposed here are:
> 
> 1.  Add a private sleepNanos method that creates/commits the JFR event around the sleep, this avoids duplicate code in the 3 sleep methods.
> 2.  Rename JVM_Sleep to JVM_SleepNanos to make it clear that it takes the sleep time in nanoseconds, esp. when Thread.sleep's parameter is milliseconds.

This pull request has now been integrated.

Changeset: 227656f3
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/227656f3a9b61ebcadab6b90ce4d53f4e351f650
Stats:     77 lines in 10 files changed: 29 ins; 32 del; 16 mod

8309408: Thread.sleep cleanup

Reviewed-by: dholmes, stefank

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

PR: https://git.openjdk.org/jdk/pull/14303

From kevinw at openjdk.org  Fri Jun 16 08:43:08 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 16 Jun 2023 08:43:08 GMT
Subject: Integrated: 8303916: ThreadLists.java inconsistent results
In-Reply-To: <H3WNK3qa7r4NXwPkjzAo8kIgus6c9VedG5F64t0plH8=.762a0531-40da-4f1c-8ba2-acd278417e30@github.com>
References: <H3WNK3qa7r4NXwPkjzAo8kIgus6c9VedG5F64t0plH8=.762a0531-40da-4f1c-8ba2-acd278417e30@github.com>
Message-ID: <fXp_zQKfXsCXp-xVu33ShVdIqz3s3hLAr6KzdIy2PvQ=.c7f6dec6-6ddd-4edf-ac3e-7f1fdbb90665@github.com>

On Wed, 14 Jun 2023 09:30:49 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test fails when additional threads are created, as it compares thread lists from different sources and sees a mismatch.
> 
> It needs to tolerate some threads with certain names appearing, e.g. JVMCI and ForkJoin threads.  If there are extra threads in the thread ID list from the ThreadMBean, remove them from the thread count before comparing.
> 
> When it fails, additionally print the ids and names of threads that it got from the MBean.
> 
> I found the test quite confusing, the naming of thread counts, arrays of threads, and arrays of thread stacktraces from different sources, so have renamed some things.

This pull request has now been integrated.

Changeset: 8c9b85a9
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8c9b85a990d955487f9141207cc83d0051defc57
Stats:     77 lines in 1 file changed: 54 ins; 1 del; 22 mod

8303916: ThreadLists.java inconsistent results

Reviewed-by: cjplummer, dholmes, lmesnik

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

PR: https://git.openjdk.org/jdk/pull/14465

From aboldtch at openjdk.org  Fri Jun 16 09:22:33 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 16 Jun 2023 09:22:33 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing
Message-ID: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>

The current implementation for testing generational ZGC with jtreg is implemented with a filter on the mode flag `ZGenerational`. Because of this only environments which set this flag explicitly will run most of the tests. 
So they get missed in Github Actions and for developers running jtreg locally without supplying the `ZGenerational` flag.

The proposed change here is to introduce two new jtreg requirement properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will effectively behave the same as the existing `vm.gc.<GC>` flags but also take the specific ZGC mode in account.

If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be true.

If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will also be true.

If `-XX:{+,-}ZGenerational` is supplied then either  `vm.gc.ZGenerational` or `vm.gc.ZSingelgen` be true depending on the flags value.

And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be false.

This change also splits the relevant tests into two distinct runs for the two modes. And the respective test ids are set to `ZGenerational` or `ZSinglegen` to make it easier to distinguish the runs.

This also solves the issue that some compiler tests will never run with generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the current filter `vm.opt.final.ZGenerational` requires the flag to be explicit, but these compiler tests uses `vm.flagless`. 

The introduction of  `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` harmonizes the way you specify generational / single gen ZGC test with the way it is done for other gcs with `vm.gc.<GC>`

To support this feature the Whitebox API is extended with `isDefaultVMFlag` to enable checking if `ZGenerational` is default or not.

`vm.opt.final.ZGenerational` is still kept because we still have some reasons to filter based on the supplied flags. 
- `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when running with ZGenerational
- `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with a different max heap size for ZGenerational, but it is not the intent to dispatch the test to both G1 and generational ZGC if Generational ZGC is not specified.  

`test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed to not filter but instead dispatch. However unsure if this change should be included. The change is isolated in 5c0c0bdab9012a5f35dd4ab3a2847374578c8b9f . It seems more appropriate to actually test the MXBeans by default with no explicit gc, but I am open reverting this part.

The plan is to also backport this to 21 to improve the testing until release. The changes here should fall under `P1?P5 doc/test changes`

Running tests in Oracle CI. (tier1-tier5)
Verified that both `ZGenerational` and `ZSinglegen` tests get run in GHA.
Running tests in builds with `--disable-jvm-feature-zgc` to verify no regression.

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

Commit messages:
 - MemoryTest.java run when not explicit
 - Add vm.gc.{ZGenerational,ZSinglegen} to jtreg

Changes: https://git.openjdk.org/jdk/pull/14509/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14509&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310187
  Stats: 618 lines in 70 files changed: 447 ins; 5 del; 166 mod
  Patch: https://git.openjdk.org/jdk/pull/14509.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14509/head:pull/14509

PR: https://git.openjdk.org/jdk/pull/14509

From kevinw at openjdk.org  Fri Jun 16 09:23:38 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 16 Jun 2023 09:23:38 GMT
Subject: RFR: 8303916: ThreadLists.java inconsistent results
Message-ID: <EM-gSGWADuTyVdSaS_8MNv8pMUUGz6JRFidTnHww304=.8747b919-93e6-46ef-aac9-0da01c80033b@github.com>

Clean backport from latest jdk repo to jdk21 for the test change:
8303916: ThreadLists.java inconsistent results

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

Commit messages:
 - Backport 8c9b85a990d955487f9141207cc83d0051defc57

Changes: https://git.openjdk.org/jdk21/pull/24/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=24&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303916
  Stats: 77 lines in 1 file changed: 54 ins; 1 del; 22 mod
  Patch: https://git.openjdk.org/jdk21/pull/24.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/24/head:pull/24

PR: https://git.openjdk.org/jdk21/pull/24

From mbaesken at openjdk.org  Fri Jun 16 10:52:28 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 16 Jun 2023 10:52:28 GMT
Subject: RFR: JDK-8310191:
 com/sun/tools/attach/warnings/DynamicLoadWarningTest.java second failure on
 AIX
Message-ID: <w95pFP0nvGtt4jqpsO6hvX5LC1T4YZ19Qd8Z4uSsg1A=.58f39222-9e68-4ebf-8d9c-e68a2acaeaf6@github.com>

After push of [JDK-8307478](https://bugs.openjdk.org/browse/JDK-8307478) , the following test started to fail on AIX :
com/sun/tools/attach/warnings/DynamicLoadWarningTest.java ; failure output :

java.lang.RuntimeException: 'WARNING: A JVM TI agent has been loaded dynamically' found in stderr
at jdk.test.lib.process.OutputAnalyzer.stderrShouldNotContain(OutputAnalyzer.java:320)
at DynamicLoadWarningTest$AppRunner.stderrShouldNotContain(DynamicLoadWarningTest.java:308)
at DynamicLoadWarningTest.testLoadOneJvmtiAgent(DynamicLoadWarningTest.java:138)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
at java.base/java.lang.reflect.Method.invoke(Method.java:580)

Should be handled in a similar way to [JDK-8309549](https://bugs.openjdk.org/browse/JDK-8309549) .

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

Commit messages:
 - JDK-8310191

Changes: https://git.openjdk.org/jdk/pull/14515/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14515&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310191
  Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14515.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14515/head:pull/14515

PR: https://git.openjdk.org/jdk/pull/14515

From alanb at openjdk.org  Fri Jun 16 11:33:58 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 Jun 2023 11:33:58 GMT
Subject: RFR: JDK-8310191:
 com/sun/tools/attach/warnings/DynamicLoadWarningTest.java second failure on
 AIX
In-Reply-To: <w95pFP0nvGtt4jqpsO6hvX5LC1T4YZ19Qd8Z4uSsg1A=.58f39222-9e68-4ebf-8d9c-e68a2acaeaf6@github.com>
References: <w95pFP0nvGtt4jqpsO6hvX5LC1T4YZ19Qd8Z4uSsg1A=.58f39222-9e68-4ebf-8d9c-e68a2acaeaf6@github.com>
Message-ID: <r1ReelkU691SLNwaZFqhQQnT5tBfxgHnB_TB5qO5O-Y=.4d77b16e-594f-481a-97f3-48425fef9af6@github.com>

On Fri, 16 Jun 2023 10:44:47 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After push of [JDK-8307478](https://bugs.openjdk.org/browse/JDK-8307478) , the following test started to fail on AIX :
> com/sun/tools/attach/warnings/DynamicLoadWarningTest.java ; failure output :
> 
> java.lang.RuntimeException: 'WARNING: A JVM TI agent has been loaded dynamically' found in stderr
> at jdk.test.lib.process.OutputAnalyzer.stderrShouldNotContain(OutputAnalyzer.java:320)
> at DynamicLoadWarningTest$AppRunner.stderrShouldNotContain(DynamicLoadWarningTest.java:308)
> at DynamicLoadWarningTest.testLoadOneJvmtiAgent(DynamicLoadWarningTest.java:138)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> 
> Should be handled in a similar way to [JDK-8309549](https://bugs.openjdk.org/browse/JDK-8309549) .

Yes, same issue as JDK-8309549.

Would you mind grouping the two tests that load the same agent library twice? That would mean the isAIX check is in one place, e.g.



diff --git a/test/jdk/com/sun/tools/attach/warnings/DynamicLoadWarningTest.java b/test/jdk/com/sun/tools/attach/warnings/DynamicLoadWarningTest.java
index 4e341b4e274..970bade3530 100644
--- a/test/jdk/com/sun/tools/attach/warnings/DynamicLoadWarningTest.java
+++ b/test/jdk/com/sun/tools/attach/warnings/DynamicLoadWarningTest.java
@@ -119,23 +119,23 @@ class DynamicLoadWarningTest {
         test().whenRunning(loadJvmtiAgent1)
                 .stderrShouldContain(JVMTI_AGENT_WARNING);
 
-        // dynamically load loadJvmtiAgent1 twice, should be one warning on platforms
-        // that can detect if an agent library was previously loaded
-        if (!Platform.isAix()) {
-            test().whenRunning(loadJvmtiAgent1)
-                    .whenRunning(loadJvmtiAgent1)
-                    .stderrShouldContain(JVMTI_AGENT_WARNING, 1);
-        }
-
         // opt-in via command line option to allow dynamic loading of agents
         test().withOpts("-XX:+EnableDynamicAgentLoading")
                 .whenRunning(loadJvmtiAgent1)
                 .stderrShouldNotContain(JVMTI_AGENT_WARNING);
 
-        // start loadJvmtiAgent1 via the command line, then dynamically load loadJvmtiAgent1
-        test().withOpts("-agentpath:" + jvmtiAgentPath1)
-                .whenRunning(loadJvmtiAgent1)
-                .stderrShouldNotContain(JVMTI_AGENT_WARNING);
+        // test behavior on platforms that can detect if an agent library was previously loaded
+        if (!Platform.isAix()) {
+            // start loadJvmtiAgent1 via the command line, then dynamically load loadJvmtiAgent1
+            test().withOpts("-agentpath:" + jvmtiAgentPath1)
+                    .whenRunning(loadJvmtiAgent1)
+                    .stderrShouldNotContain(JVMTI_AGENT_WARNING);
+
+            // dynamically load loadJvmtiAgent1 twice, should be one warning
+            test().whenRunning(loadJvmtiAgent1)
+                    .whenRunning(loadJvmtiAgent1)
+                    .stderrShouldContain(JVMTI_AGENT_WARNING, 1);
+        }
     }

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

PR Comment: https://git.openjdk.org/jdk/pull/14515#issuecomment-1594532957

From aboldtch at openjdk.org  Fri Jun 16 11:41:14 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 16 Jun 2023 11:41:14 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v2]
In-Reply-To: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
Message-ID: <XdYB_LK_u2E2ai0OiXTAZngiUyo0mkSV43XSQ95tAbM=.2accc74d-4765-4685-8f70-c683d93dbe25@github.com>

> The current implementation for testing generational ZGC with jtreg is implemented with a filter on the mode flag `ZGenerational`. Because of this only environments which set this flag explicitly will run most of the tests. 
> So they get missed in Github Actions and for developers running jtreg locally without supplying the `ZGenerational` flag.
> 
> The proposed change here is to introduce two new jtreg requirement properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will effectively behave the same as the existing `vm.gc.<GC>` flags but also take the specific ZGC mode in account.
> 
> If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be true.
> 
> If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will also be true.
> 
> If `-XX:{+,-}ZGenerational` is supplied then either  `vm.gc.ZGenerational` or `vm.gc.ZSingelgen` be true depending on the flags value.
> 
> And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be false.
> 
> This change also splits the relevant tests into two distinct runs for the two modes. And the respective test ids are set to `ZGenerational` or `ZSinglegen` to make it easier to distinguish the runs.
> 
> This also solves the issue that some compiler tests will never run with generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the current filter `vm.opt.final.ZGenerational` requires the flag to be explicit, but these compiler tests uses `vm.flagless`. 
> 
> The introduction of  `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` harmonizes the way you specify generational / single gen ZGC test with the way it is done for other gcs with `vm.gc.<GC>`
> 
> To support this feature the Whitebox API is extended with `isDefaultVMFlag` to enable checking if `ZGenerational` is default or not.
> 
> `vm.opt.final.ZGenerational` is still kept because we still have some reasons to filter based on the supplied flags. 
> - `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when running with ZGenerational
> - `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with a different max heap size for ZGenerational, but it is not the intent to dispatch the test to both G1 and generational ZGC if Generational ZGC is not specified.  
> 
> `test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed to not filter but instead dispatch. However unsure if this change should be included. The change ...

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Fix wrong ZGenerational flag in VectorRebracket128Test.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14509/files
  - new: https://git.openjdk.org/jdk/pull/14509/files/5c0c0bda..e571b87f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14509&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14509&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14509.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14509/head:pull/14509

PR: https://git.openjdk.org/jdk/pull/14509

From stefank at openjdk.org  Fri Jun 16 11:47:58 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 16 Jun 2023 11:47:58 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v2]
In-Reply-To: <XdYB_LK_u2E2ai0OiXTAZngiUyo0mkSV43XSQ95tAbM=.2accc74d-4765-4685-8f70-c683d93dbe25@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
 <XdYB_LK_u2E2ai0OiXTAZngiUyo0mkSV43XSQ95tAbM=.2accc74d-4765-4685-8f70-c683d93dbe25@github.com>
Message-ID: <DD112bPIhXJScIUoRZ66n3fOFY0qVi17pZqs535oN3c=.ebe61b64-0869-4bfc-80dc-1e532a1be770@github.com>

On Fri, 16 Jun 2023 11:41:14 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The current implementation for testing generational ZGC with jtreg is implemented with a filter on the mode flag `ZGenerational`. Because of this only environments which set this flag explicitly will run most of the tests. 
>> So they get missed in Github Actions and for developers running jtreg locally without supplying the `ZGenerational` flag.
>> 
>> The proposed change here is to introduce two new jtreg requirement properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will effectively behave the same as the existing `vm.gc.<GC>` flags but also take the specific ZGC mode in account.
>> 
>> If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be true.
>> 
>> If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will also be true.
>> 
>> If `-XX:{+,-}ZGenerational` is supplied then either  `vm.gc.ZGenerational` or `vm.gc.ZSingelgen` be true depending on the flags value.
>> 
>> And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be false.
>> 
>> This change also splits the relevant tests into two distinct runs for the two modes. And the respective test ids are set to `ZGenerational` or `ZSinglegen` to make it easier to distinguish the runs.
>> 
>> This also solves the issue that some compiler tests will never run with generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the current filter `vm.opt.final.ZGenerational` requires the flag to be explicit, but these compiler tests uses `vm.flagless`. 
>> 
>> The introduction of  `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` harmonizes the way you specify generational / single gen ZGC test with the way it is done for other gcs with `vm.gc.<GC>`
>> 
>> To support this feature the Whitebox API is extended with `isDefaultVMFlag` to enable checking if `ZGenerational` is default or not.
>> 
>> `vm.opt.final.ZGenerational` is still kept because we still have some reasons to filter based on the supplied flags. 
>> - `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when running with ZGenerational
>> - `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with a different max heap size for ZGenerational, but it is not the intent to dispatch the test to both G1 and generational ZGC if Generational ZGC is not specified.  
>> 
>> `test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed to not filter but instead dispatch. However u...
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix wrong ZGenerational flag in VectorRebracket128Test.java

Looks good.

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14509#pullrequestreview-1483282594

From mbaesken at openjdk.org  Fri Jun 16 11:59:39 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 16 Jun 2023 11:59:39 GMT
Subject: RFR: JDK-8310191:
 com/sun/tools/attach/warnings/DynamicLoadWarningTest.java second failure on
 AIX [v2]
In-Reply-To: <w95pFP0nvGtt4jqpsO6hvX5LC1T4YZ19Qd8Z4uSsg1A=.58f39222-9e68-4ebf-8d9c-e68a2acaeaf6@github.com>
References: <w95pFP0nvGtt4jqpsO6hvX5LC1T4YZ19Qd8Z4uSsg1A=.58f39222-9e68-4ebf-8d9c-e68a2acaeaf6@github.com>
Message-ID: <ohZ5WzVwEneaGJsOOHcqchTZYZGDZkG5GgiAg_TkTO8=.b1a1c000-a575-49be-8815-f235b82365d4@github.com>

> After push of [JDK-8307478](https://bugs.openjdk.org/browse/JDK-8307478) , the following test started to fail on AIX :
> com/sun/tools/attach/warnings/DynamicLoadWarningTest.java ; failure output :
> 
> java.lang.RuntimeException: 'WARNING: A JVM TI agent has been loaded dynamically' found in stderr
> at jdk.test.lib.process.OutputAnalyzer.stderrShouldNotContain(OutputAnalyzer.java:320)
> at DynamicLoadWarningTest$AppRunner.stderrShouldNotContain(DynamicLoadWarningTest.java:308)
> at DynamicLoadWarningTest.testLoadOneJvmtiAgent(DynamicLoadWarningTest.java:138)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> 
> Should be handled in a similar way to [JDK-8309549](https://bugs.openjdk.org/browse/JDK-8309549) .

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Rearrange and simplify test coding

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14515/files
  - new: https://git.openjdk.org/jdk/pull/14515/files/8694eb48..af005ebc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14515&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14515&range=00-01

  Stats: 15 lines in 1 file changed: 6 ins; 8 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14515.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14515/head:pull/14515

PR: https://git.openjdk.org/jdk/pull/14515

From mbaesken at openjdk.org  Fri Jun 16 11:59:39 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 16 Jun 2023 11:59:39 GMT
Subject: RFR: JDK-8310191:
 com/sun/tools/attach/warnings/DynamicLoadWarningTest.java second failure on
 AIX
In-Reply-To: <w95pFP0nvGtt4jqpsO6hvX5LC1T4YZ19Qd8Z4uSsg1A=.58f39222-9e68-4ebf-8d9c-e68a2acaeaf6@github.com>
References: <w95pFP0nvGtt4jqpsO6hvX5LC1T4YZ19Qd8Z4uSsg1A=.58f39222-9e68-4ebf-8d9c-e68a2acaeaf6@github.com>
Message-ID: <YO_meYD1ENUnnBA2AS_DLqLzQVawrxX4QmGeXgVR3aI=.890ab38c-afe0-429d-92de-785b1ce040b1@github.com>

On Fri, 16 Jun 2023 10:44:47 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After push of [JDK-8307478](https://bugs.openjdk.org/browse/JDK-8307478) , the following test started to fail on AIX :
> com/sun/tools/attach/warnings/DynamicLoadWarningTest.java ; failure output :
> 
> java.lang.RuntimeException: 'WARNING: A JVM TI agent has been loaded dynamically' found in stderr
> at jdk.test.lib.process.OutputAnalyzer.stderrShouldNotContain(OutputAnalyzer.java:320)
> at DynamicLoadWarningTest$AppRunner.stderrShouldNotContain(DynamicLoadWarningTest.java:308)
> at DynamicLoadWarningTest.testLoadOneJvmtiAgent(DynamicLoadWarningTest.java:138)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> 
> Should be handled in a similar way to [JDK-8309549](https://bugs.openjdk.org/browse/JDK-8309549) .

Hi Alan, I adjusted / simplified the coding.

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

PR Comment: https://git.openjdk.org/jdk/pull/14515#issuecomment-1594561066

From eosterlund at openjdk.org  Fri Jun 16 12:07:00 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 16 Jun 2023 12:07:00 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v2]
In-Reply-To: <XdYB_LK_u2E2ai0OiXTAZngiUyo0mkSV43XSQ95tAbM=.2accc74d-4765-4685-8f70-c683d93dbe25@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
 <XdYB_LK_u2E2ai0OiXTAZngiUyo0mkSV43XSQ95tAbM=.2accc74d-4765-4685-8f70-c683d93dbe25@github.com>
Message-ID: <G9Rk1_psrvYyebtTVJBVhAjrIyvfGwn1AiXCJZkZLxM=.5c2ef27a-7498-4f31-96e4-588c3d33b307@github.com>

On Fri, 16 Jun 2023 11:41:14 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The current implementation for testing generational ZGC with jtreg is implemented with a filter on the mode flag `ZGenerational`. Because of this only environments which set this flag explicitly will run most of the tests. 
>> So they get missed in Github Actions and for developers running jtreg locally without supplying the `ZGenerational` flag.
>> 
>> The proposed change here is to introduce two new jtreg requirement properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will effectively behave the same as the existing `vm.gc.<GC>` flags but also take the specific ZGC mode in account.
>> 
>> If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be true.
>> 
>> If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will also be true.
>> 
>> If `-XX:{+,-}ZGenerational` is supplied then either  `vm.gc.ZGenerational` or `vm.gc.ZSingelgen` be true depending on the flags value.
>> 
>> And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be false.
>> 
>> This change also splits the relevant tests into two distinct runs for the two modes. And the respective test ids are set to `ZGenerational` or `ZSinglegen` to make it easier to distinguish the runs.
>> 
>> This also solves the issue that some compiler tests will never run with generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the current filter `vm.opt.final.ZGenerational` requires the flag to be explicit, but these compiler tests uses `vm.flagless`. 
>> 
>> The introduction of  `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` harmonizes the way you specify generational / single gen ZGC test with the way it is done for other gcs with `vm.gc.<GC>`
>> 
>> To support this feature the Whitebox API is extended with `isDefaultVMFlag` to enable checking if `ZGenerational` is default or not.
>> 
>> `vm.opt.final.ZGenerational` is still kept because we still have some reasons to filter based on the supplied flags. 
>> - `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when running with ZGenerational
>> - `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with a different max heap size for ZGenerational, but it is not the intent to dispatch the test to both G1 and generational ZGC if Generational ZGC is not specified.  
>> 
>> `test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed to not filter but instead dispatch. However u...
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix wrong ZGenerational flag in VectorRebracket128Test.java

Looks good.

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

Marked as reviewed by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14509#pullrequestreview-1483348038

From stefank at openjdk.org  Fri Jun 16 12:13:29 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 16 Jun 2023 12:13:29 GMT
Subject: RFR: 8310194: Generational ZGC: Lock-order asserts in JVMTI
 IterateThroughHeap
Message-ID: <JFgqaXsFv8JyuOzQuXC3sioAeiGTZxTiw-4gnX-j6Ok=.6a2ceeb4-b304-46cb-be4e-9816beeb7d6a@github.com>

Generational ZGC changed the location where the heap object iterator called the visit function. It used to be called when the objects were popped and then followed, but it was changed so that the function where called immediately when the objects are marked. This gave the benefit that the verification code code show exactly what root had a broken object. Unfortunately, this change started to apply non-GC closure during the root iteration. This code lead to lock order issues, just like the one described in the JBS entry.

This fix moves the visit calls for non-GC closures back to the follow calls.

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

Commit messages:
 - Clean out old comment
 - 8310194: Generational ZGC: Lock order asserts in JVMTI IterateThroughHeap

Changes: https://git.openjdk.org/jdk/pull/14518/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14518&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310194
  Stats: 203 lines in 5 files changed: 103 ins; 37 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/14518.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14518/head:pull/14518

PR: https://git.openjdk.org/jdk/pull/14518

From stefank at openjdk.org  Fri Jun 16 12:13:29 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 16 Jun 2023 12:13:29 GMT
Subject: RFR: 8310194: Generational ZGC: Lock-order asserts in JVMTI
 IterateThroughHeap
In-Reply-To: <JFgqaXsFv8JyuOzQuXC3sioAeiGTZxTiw-4gnX-j6Ok=.6a2ceeb4-b304-46cb-be4e-9816beeb7d6a@github.com>
References: <JFgqaXsFv8JyuOzQuXC3sioAeiGTZxTiw-4gnX-j6Ok=.6a2ceeb4-b304-46cb-be4e-9816beeb7d6a@github.com>
Message-ID: <hLEOeImTFr0z6EmCenvYktBFC8G9lpWcfJcxxwUw2f4=.1665b330-b63e-4dea-ab8f-a5180cf3a29d@github.com>

On Fri, 16 Jun 2023 11:52:51 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Generational ZGC changed the location where the heap object iterator called the visit function. It used to be called when the objects were popped and then followed, but it was changed so that the function where called immediately when the objects are marked. This gave the benefit that the verification code code show exactly what root had a broken object. Unfortunately, this change started to apply non-GC closure during the root iteration. This code lead to lock order issues, just like the one described in the JBS entry.
> 
> This fix moves the visit calls for non-GC closures back to the follow calls.

It was quite hard to provoke this problem, and this bug was found in one of Oracle's internal stress tests. The stack trace looked like this:

#  assert(false) failed: Attempting to acquire lock ObjectSynchronizer Weak alloc lock/oopstorage out of order with lock Service_lock/service -- possible deadlock
...
V  [libjvm.so+0x13fcc3c]  Mutex::check_rank(Thread*)+0x36c  (mutex.cpp:447)
V  [libjvm.so+0x13fdee0]  Mutex::lock_without_safepoint_check()+0x50  (mutex.cpp:145)
V  [libjvm.so+0x14819b9]  OopStorage::allocate()+0x29  (mutexLocker.hpp:199)
V  [libjvm.so+0x18a8bd0]  WeakHandle::WeakHandle(OopStorage*, oop)+0x20  (weakHandle.cpp:37)
V  [libjvm.so+0x144e4f2]  ObjectMonitor::ObjectMonitor(oop)+0x62  (objectMonitor.cpp:261)
V  [libjvm.so+0x17337f5]  ObjectSynchronizer::inflate(Thread*, oop, ObjectSynchronizer::InflateCause)+0x675  (synchronizer.cpp:1425)
V  [libjvm.so+0x1736036]  ObjectSynchronizer::FastHashCode(Thread*, oop)+0x146  (synchronizer.cpp:1001)
V  [libjvm.so+0x146491f]  oopDesc::slow_identity_hash()+0x6f  (oop.cpp:112)
V  [libjvm.so+0x11bf2c5]  JvmtiTagMapTable::remove(oop)+0x265  (oop.inline.hpp:366)
V  [libjvm.so+0x11b6e0f]  CallbackWrapper::~CallbackWrapper()+0xef  (jvmtiTagMap.cpp:248)
V  [libjvm.so+0x11b290c]  IterateThroughHeapObjectClosure::do_object(oop)+0x59c  (jvmtiTagMap.cpp:1089)
V  [libjvm.so+0x1999518]  ZHeapIteratorContext::mark_and_push(oop) const [clone .part.0]+0x58  (zHeapIterator.cpp:81)
V  [libjvm.so+0x199c6d4]  ZHeapIteratorUncoloredRootOopClosure::do_oop(oop*)+0x154  (zHeapIterator.cpp:161)
V  [libjvm.so+0x19bda57]  ZNMethod::nmethod_oops_do_inner(nmethod*, OopClosure*)+0x47  (zNMethod.cpp:264)
V  [libjvm.so+0x19bdc1e]  ZNMethod::nmethod_oops_do(nmethod*, OopClosure*)+0x8e  (zNMethod.cpp:254)
V  [libjvm.so+0x1196195]  JvmtiDeferredEventQueue::oops_do(OopClosure*, CodeBlobClosure*)+0x45  (jvmtiImpl.cpp:1027)
V  [libjvm.so+0x15e5dd9]  ServiceThread::oops_do_no_frames(OopClosure*, CodeBlobClosure*)+0x59  (serviceThread.cpp:220)
V  [libjvm.so+0x1796ac6]  Thread::oops_do(OopClosure*, CodeBlobClosure*)+0x76  (thread.cpp:431)
V  [libjvm.so+0x19fad72]  ZJavaThreadsIterator::apply(ThreadClosure*)+0x102  (zRootsIterator.cpp:136)
V  [libjvm.so+0x19fb135]  ZRootsIteratorStrongUncolored::apply(ThreadClosure*, NMethodClosure*)+0x35  (zRootsIterator.cpp:96)
V  [libjvm.so+0x1997bed]  ZHeapIterator::push_strong_roots(ZHeapIteratorContext const&)+0x10d  (zHeapIterator.cpp:376)
V  [libjvm.so+0x199a37c]  ZHeapIterator::object_iterate(ObjectClosure*, unsigned int)+0x7c  (zHeapIterator.cpp:388)
V  [libjvm.so+0x199476e]  ZHeap::object_iterate(ObjectClosure*, bool)+0x5e  (zHeap.cpp:297)
V  [libjvm.so+0x11b787c]  VM_HeapIterateOperation::doit()+0x5c  (jvmtiTagMap.cpp:877)

You had to provoke the ObjectMonitor inflate code path via the identify_hash call from the JVMTI tagmap code, while the ServiceThread had a registered deferred event.
Note that the Service_lock is taken inside ServiceThread::oops_do_no_frames.

To more easily provoke the bug I temporarily added a oopstorage-ranked lock to IterateThroughHeapObjectClosure:

diff --git a/src/hotspot/share/prims/jvmtiTagMap.cpp b/src/hotspot/share/prims/jvmtiTagMap.cpp
index 6908e1994ba..a0e031eec31 100644
--- a/src/hotspot/share/prims/jvmtiTagMap.cpp
+++ b/src/hotspot/share/prims/jvmtiTagMap.cpp
@@ -967,6 +967,8 @@ class IterateThroughHeapObjectClosure: public ObjectClosure {
   const jvmtiHeapCallbacks* _callbacks;
   const void* _user_data;
 
+  Mutex _lock;
+
   // accessor functions
   JvmtiTagMap* tag_map() const                     { return _tag_map; }
   int heap_filter() const                          { return _heap_filter; }
@@ -1000,6 +1002,7 @@ class IterateThroughHeapObjectClosure: public ObjectClosure {
     _heap_filter(heap_filter),
     _callbacks(heap_callbacks),
     _user_data(user_data),
+    _lock(Mutex::oopstorage, "Test lock"),
     _iteration_aborted(false)
   {
   }
@@ -1009,6 +1012,10 @@ class IterateThroughHeapObjectClosure: public ObjectClosure {
 
 // invoked for each object in the heap
 void IterateThroughHeapObjectClosure::do_object(oop obj) {
+  {
+    MutexLocker locker(&_lock, Mutex::_no_safepoint_check_flag);
+  }
+
   // check if iteration has been halted
   if (is_iteration_aborted()) return;
 

With this I could consistently get the problem to reproduce within a few minutes. After moving the call to the visitor (IterateThroughHeapObjectClosure) to outside the root iterator I've been able to run the reproducer for a few hours without any asserts.

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

PR Comment: https://git.openjdk.org/jdk/pull/14518#issuecomment-1594566234

From alanb at openjdk.org  Fri Jun 16 12:26:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 Jun 2023 12:26:04 GMT
Subject: RFR: JDK-8310191:
 com/sun/tools/attach/warnings/DynamicLoadWarningTest.java second failure on
 AIX [v2]
In-Reply-To: <ohZ5WzVwEneaGJsOOHcqchTZYZGDZkG5GgiAg_TkTO8=.b1a1c000-a575-49be-8815-f235b82365d4@github.com>
References: <w95pFP0nvGtt4jqpsO6hvX5LC1T4YZ19Qd8Z4uSsg1A=.58f39222-9e68-4ebf-8d9c-e68a2acaeaf6@github.com>
 <ohZ5WzVwEneaGJsOOHcqchTZYZGDZkG5GgiAg_TkTO8=.b1a1c000-a575-49be-8815-f235b82365d4@github.com>
Message-ID: <g-szoukYvEplMBy-5Z17XLTuTF0_nzi5_hrP995YhDw=.e8a87b2d-bfb2-4525-a05f-42197850e6c4@github.com>

On Fri, 16 Jun 2023 11:59:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> After push of [JDK-8307478](https://bugs.openjdk.org/browse/JDK-8307478) , the following test started to fail on AIX :
>> com/sun/tools/attach/warnings/DynamicLoadWarningTest.java ; failure output :
>> 
>> java.lang.RuntimeException: 'WARNING: A JVM TI agent has been loaded dynamically' found in stderr
>> at jdk.test.lib.process.OutputAnalyzer.stderrShouldNotContain(OutputAnalyzer.java:320)
>> at DynamicLoadWarningTest$AppRunner.stderrShouldNotContain(DynamicLoadWarningTest.java:308)
>> at DynamicLoadWarningTest.testLoadOneJvmtiAgent(DynamicLoadWarningTest.java:138)
>> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
>> 
>> Should be handled in a similar way to [JDK-8309549](https://bugs.openjdk.org/browse/JDK-8309549) .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rearrange and simplify test coding

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14515#pullrequestreview-1483385221

From alanb at openjdk.org  Fri Jun 16 12:26:06 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 Jun 2023 12:26:06 GMT
Subject: RFR: JDK-8310191:
 com/sun/tools/attach/warnings/DynamicLoadWarningTest.java second failure on
 AIX
In-Reply-To: <YO_meYD1ENUnnBA2AS_DLqLzQVawrxX4QmGeXgVR3aI=.890ab38c-afe0-429d-92de-785b1ce040b1@github.com>
References: <w95pFP0nvGtt4jqpsO6hvX5LC1T4YZ19Qd8Z4uSsg1A=.58f39222-9e68-4ebf-8d9c-e68a2acaeaf6@github.com>
 <YO_meYD1ENUnnBA2AS_DLqLzQVawrxX4QmGeXgVR3aI=.890ab38c-afe0-429d-92de-785b1ce040b1@github.com>
Message-ID: <n2iDDblzaeITDPyAddAet3LWMg0Qhs3egljv7VXvC2Y=.b9a85a1b-1e34-43b1-939a-6f5213cd9670@github.com>

On Fri, 16 Jun 2023 11:54:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi Alan, I adjusted / simplified the coding.

Thanks for taking the suggestion.

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

PR Comment: https://git.openjdk.org/jdk/pull/14515#issuecomment-1594595016

From eosterlund at openjdk.org  Fri Jun 16 13:08:07 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 16 Jun 2023 13:08:07 GMT
Subject: RFR: 8310194: Generational ZGC: Lock-order asserts in JVMTI
 IterateThroughHeap
In-Reply-To: <JFgqaXsFv8JyuOzQuXC3sioAeiGTZxTiw-4gnX-j6Ok=.6a2ceeb4-b304-46cb-be4e-9816beeb7d6a@github.com>
References: <JFgqaXsFv8JyuOzQuXC3sioAeiGTZxTiw-4gnX-j6Ok=.6a2ceeb4-b304-46cb-be4e-9816beeb7d6a@github.com>
Message-ID: <_VrgqP0X4MnaMbW1Ay3LEZbMoyR7S6lLrUszGXAb6x0=.72792f16-b659-4472-8538-7d39120dbb1c@github.com>

On Fri, 16 Jun 2023 11:52:51 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Generational ZGC changed the location where the heap object iterator called the visit function. It used to be called when the objects were popped and then followed, but it was changed so that the function where called immediately when the objects are marked. This gave the benefit that the verification code code show exactly what root had a broken object. Unfortunately, this change started to apply non-GC closure during the root iteration. This code lead to lock order issues, just like the one described in the JBS entry.
> 
> This fix moves the visit calls for non-GC closures back to the follow calls.

Looks good.

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

Marked as reviewed by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14518#pullrequestreview-1483470046

From aboldtch at openjdk.org  Fri Jun 16 13:50:16 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 16 Jun 2023 13:50:16 GMT
Subject: RFR: 8310194: Generational ZGC: Lock-order asserts in JVMTI
 IterateThroughHeap
In-Reply-To: <JFgqaXsFv8JyuOzQuXC3sioAeiGTZxTiw-4gnX-j6Ok=.6a2ceeb4-b304-46cb-be4e-9816beeb7d6a@github.com>
References: <JFgqaXsFv8JyuOzQuXC3sioAeiGTZxTiw-4gnX-j6Ok=.6a2ceeb4-b304-46cb-be4e-9816beeb7d6a@github.com>
Message-ID: <MTk9zQjIr9kJhzcQse94MVG2-BG_WK6ImqJg1qELCu8=.cdd154bd-b8f0-4280-bc24-6dacc2204dd6@github.com>

On Fri, 16 Jun 2023 11:52:51 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Generational ZGC changed the location where the heap object iterator called the visit function. It used to be called when the objects were popped and then followed, but it was changed so that the function where called immediately when the objects are marked. This gave the benefit that the verification code code show exactly what root had a broken object. Unfortunately, this change started to apply non-GC closure during the root iteration. This code lead to lock order issues, just like the one described in the JBS entry.
> 
> This fix moves the visit calls for non-GC closures back to the follow calls.

Looks good.

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

Marked as reviewed by aboldtch (Committer).

PR Review: https://git.openjdk.org/jdk/pull/14518#pullrequestreview-1483552664

From jjg at openjdk.org  Fri Jun 16 15:09:14 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 16 Jun 2023 15:09:14 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <LQj9A4_3dfSUIozPcVuYCUF1QhseODhxAft9eKH33E4=.30cf5fee-d616-4726-8c33-1b22bfb29c26@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
 <LQj9A4_3dfSUIozPcVuYCUF1QhseODhxAft9eKH33E4=.30cf5fee-d616-4726-8c33-1b22bfb29c26@github.com>
Message-ID: <2kbH05YbpsESJdT-SJhoh4dcJ3l4rwDCYJHQTMxD9rA=.c6f3ea46-7748-495a-ae76-fd25759f517f@github.com>

On Tue, 13 Jun 2023 18:38:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Left some comments on the translations mainly in Japanese. It is now very easy to look at the l10n changes in the generated HTML. One small comment to the tool is that it would be nice if the order in HTML (alphabetically sorted currently) aligns with the order in the actual resource file. It is a great improvement anyways.

1. It is not easy to recover the order in the actual resource file: the contents are read into a `Properties` object which uses a `Hashtable` to store the data. 
2. There is no guarantee that the order is the same in all the resource files, so we would have to choose one, presumably the default one, to determine the presentation order.

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

PR Comment: https://git.openjdk.org/jdk/pull/14430#issuecomment-1594844435

From duke at openjdk.org  Fri Jun 16 16:54:01 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Fri, 16 Jun 2023 16:54:01 GMT
Subject: RFR: 8309979: BootstrapMethods attribute is missing in class files
 recreated by SA [v2]
In-Reply-To: <u1oTH8KS-kJJxLyJCylgYxzQwxLmWlzH7-SqD_VNeXY=.2b763b0b-b513-49e5-b79f-dc2874973d15@github.com>
References: <nSooA6CtKm8LsaxzYdqJ6mtVV0os-kT5F2xNvYI4lJo=.c27bd28e-88d3-4bcb-ac3d-9036140eeff0@github.com>
 <i3PjGx_wbQ63SlwcWL5eBr28sDUb1_dPQ8Q0P3Qgzds=.5f11a8e5-714c-45c0-87e6-e612bb50b28b@github.com>
 <u1oTH8KS-kJJxLyJCylgYxzQwxLmWlzH7-SqD_VNeXY=.2b763b0b-b513-49e5-b79f-dc2874973d15@github.com>
Message-ID: <ueIEUIyIEvmdSC7e1eRIvAzSYPogK05kl-FLbmEcAKI=.80447b7b-45cc-4e5a-8ce7-0a5836f349d6@github.com>

On Thu, 15 Jun 2023 23:20:56 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments by plummercj
>>   
>>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> Can you run the tests in `test/hotspot/jtreg/serviceability/sa` and `test/jdk/sun/tools/jhsdb/`? thanks.

@plummercj I ran `test/hotspot/jtreg/serviceability/sa` and `test/jdk/sun/tools/jhsdb/` . Thanks for pointing out.
I see only one failure - `test/hotspot/jtreg/serviceability/sa/TestRevPtrsForInvokeDynamic.java`. However this test failed with the same exception without this patch as well. Reason for the failure is:


 stderr: [Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: -16 19
	at jdk.hotspot.agent/sun.jvm.hotspot.oops.ResolvedIndyArray.getAt(ResolvedIndyArray.java:60)
	at jdk.hotspot.agent/sun.jvm.hotspot.oops.ConstantPoolCache.getIndyEntryAt(ConstantPoolCache.java:91)
	at jdk.hotspot.agent/sun.jvm.hotspot.oops.ConstantPool.to_cp_index(ConstantPool.java:261)
	at jdk.hotspot.agent/sun.jvm.hotspot.oops.ConstantPool.getNameAndTypeRefIndexAt(ConstantPool.java:343)
	at jdk.hotspot.agent/sun.jvm.hotspot.oops.ConstantPool.getSignatureRefAt(ConstantPool.java:303)
	at jdk.hotspot.agent/sun.jvm.hotspot.oops.GenerateOopMap.doMethod(GenerateOopMap.java:1730)
	at jdk.hotspot.agent/sun.jvm.hotspot.oops.GenerateOopMap.interp1(GenerateOopMap.java:1385)
	at jdk.hotspot.agent/sun.jvm.hotspot.oops.GenerateOopMap.interpBB(GenerateOopMap.java:802)
	at jdk.hotspot.agent/sun.jvm.hotspot.oops.GenerateOopMap.interpAll(GenerateOopMap.java:1108)
	at jdk.hotspot.agent/sun.jvm.hotspot.oops.GenerateOopMap.doInterpretation(GenerateOopMap.java:981)
	at jdk.hotspot.agent/sun.jvm.hotspot.oops.GenerateOopMap.computeMap(GenerateOopMap.java:2198)
	at jdk.hotspot.agent/sun.jvm.hotspot.interpreter.OopMapForCacheEntry.computeMap(OopMapForCacheEntry.java:80)
	at jdk.hotspot.agent/sun.jvm.hotspot.interpreter.OopMapCacheEntry.fill(OopMapCacheEntry.java:53)
	at jdk.hotspot.agent/sun.jvm.hotspot.oops.Method.getMaskFor(Method.java:257)
	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.oopsInterpretedDo(Frame.java:590)
	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.oopsDo(Frame.java:442)
	at jdk.hotspot.agent/sun.jvm.hotspot.utilities.ReversePtrsAnalysis.doStack(ReversePtrsAnalysis.java:297)
	at jdk.hotspot.agent/sun.jvm.hotspot.utilities.ReversePtrsAnalysis.run(ReversePtrsAnalysis.java:102)
	at TestRevPtrsForInvokeDynamic.computeReversePointers(TestRevPtrsForInvokeDynamic.java:60)
	at TestRevPtrsForInvokeDynamic.main(TestRevPtrsForInvokeDynamic.java:92)


It looks like this test is already in the ProblemList because of [JDK-8241235](https://bugs.openjdk.org/browse/JDK-8241235).

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

PR Comment: https://git.openjdk.org/jdk/pull/14495#issuecomment-1594974422

From naoto at openjdk.org  Fri Jun 16 17:16:33 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 16 Jun 2023 17:16:33 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <2kbH05YbpsESJdT-SJhoh4dcJ3l4rwDCYJHQTMxD9rA=.c6f3ea46-7748-495a-ae76-fd25759f517f@github.com>
References: <XFn64Oh_GVy3S9oaaUk5yn-ZVFv-u3wSVgIxWItoaas=.e92c3580-1a67-4468-8b64-06b0f64ff7fb@github.com>
 <mcjjUpw2dfEqPbqGeJScbYZpuKkyFuZ5QeULVzvDxfk=.5f24e876-5fb4-4a72-94a6-ffc2dc4e4ce9@github.com>
 <LQj9A4_3dfSUIozPcVuYCUF1QhseODhxAft9eKH33E4=.30cf5fee-d616-4726-8c33-1b22bfb29c26@github.com>
 <2kbH05YbpsESJdT-SJhoh4dcJ3l4rwDCYJHQTMxD9rA=.c6f3ea46-7748-495a-ae76-fd25759f517f@github.com>
Message-ID: <mnwQXQ-yvvAdB4JlfTC3NwMpbuEENwDTX0GeETglGh0=.9054a675-049f-4dfb-a847-4e93fea5020f@github.com>

On Fri, 16 Jun 2023 15:06:30 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Left some comments on the translations mainly in Japanese. It is now very easy to look at the l10n changes in the generated HTML. One small comment to the tool is that it would be nice if the order in HTML (alphabetically sorted currently) aligns with the order in the actual resource file. It is a great improvement anyways.
>
>> Left some comments on the translations mainly in Japanese. It is now very easy to look at the l10n changes in the generated HTML. One small comment to the tool is that it would be nice if the order in HTML (alphabetically sorted currently) aligns with the order in the actual resource file. It is a great improvement anyways.
> 
> 1. It is not easy to recover the order in the actual resource file: the contents are read into a `Properties` object which uses a `Hashtable` to store the data. 
> 2. There is no guarantee that the order is the same in all the resource files, so we would have to choose one, presumably the default one, to determine the presentation order.
> 3. The iteration order would be undefined when resources are removed from one or more resource files

Makes sense. Thanks for the explanation @jonathan-gibbons

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

PR Comment: https://git.openjdk.org/jdk/pull/14430#issuecomment-1594999086

From dcubed at openjdk.org  Fri Jun 16 17:42:11 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 16 Jun 2023 17:42:11 GMT
Subject: Integrated: 8310211:
 serviceability/jvmti/thread/GetStackTrace/getstacktr03/getstacktr03.java
 failing
Message-ID: <HUYxuELf38qqMME-4Wv5yrvU1Dg6QdxwbgyCi9uOpIQ=.33adeeb0-3a7f-4926-8c09-d8838b8396b6@github.com>

A trivia fix for serviceability/jvmti/thread/GetStackTrace/getstacktr03/getstacktr03.java failing.

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

Commit messages:
 - 8310211: serviceability/jvmti/thread/GetStackTrace/getstacktr03/getstacktr03.java failing

Changes: https://git.openjdk.org/jdk/pull/14524/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14524&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310211
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14524.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14524/head:pull/14524

PR: https://git.openjdk.org/jdk/pull/14524

From mikael at openjdk.org  Fri Jun 16 17:42:11 2023
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Fri, 16 Jun 2023 17:42:11 GMT
Subject: Integrated: 8310211:
 serviceability/jvmti/thread/GetStackTrace/getstacktr03/getstacktr03.java
 failing
In-Reply-To: <HUYxuELf38qqMME-4Wv5yrvU1Dg6QdxwbgyCi9uOpIQ=.33adeeb0-3a7f-4926-8c09-d8838b8396b6@github.com>
References: <HUYxuELf38qqMME-4Wv5yrvU1Dg6QdxwbgyCi9uOpIQ=.33adeeb0-3a7f-4926-8c09-d8838b8396b6@github.com>
Message-ID: <4-EbMiHgV6CKGswkciMMgncw2MLV3KAP3bTVudtWrVk=.945d6abf-3829-4723-bd1c-6e80a9204334@github.com>

On Fri, 16 Jun 2023 17:10:08 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivia fix for serviceability/jvmti/thread/GetStackTrace/getstacktr03/getstacktr03.java failing.

Marked as reviewed by mikael (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14524#pullrequestreview-1484002823

From dcubed at openjdk.org  Fri Jun 16 17:42:12 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 16 Jun 2023 17:42:12 GMT
Subject: Integrated: 8310211:
 serviceability/jvmti/thread/GetStackTrace/getstacktr03/getstacktr03.java
 failing
In-Reply-To: <HUYxuELf38qqMME-4Wv5yrvU1Dg6QdxwbgyCi9uOpIQ=.33adeeb0-3a7f-4926-8c09-d8838b8396b6@github.com>
References: <HUYxuELf38qqMME-4Wv5yrvU1Dg6QdxwbgyCi9uOpIQ=.33adeeb0-3a7f-4926-8c09-d8838b8396b6@github.com>
Message-ID: <_qrYWoQbCLdMRPRadZ5wIyrK86CXwLfdDDvSPnzP9po=.e74c22d6-7d12-4d27-99da-b95e81757172@github.com>

On Fri, 16 Jun 2023 17:10:08 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivia fix for serviceability/jvmti/thread/GetStackTrace/getstacktr03/getstacktr03.java failing.

This fix is being tested with an urgent Mach5 Tier1.

macosx-aarch64-debug has passed the test when it failed before.

linux-x64-debug has passed the test where it failed before...

windows-x64-debug has passed the test where it failed before...

linux-aarch64-debug has passed the test where it failed before...

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

PR Comment: https://git.openjdk.org/jdk/pull/14524#issuecomment-1595004554
PR Comment: https://git.openjdk.org/jdk/pull/14524#issuecomment-1595005744
PR Comment: https://git.openjdk.org/jdk/pull/14524#issuecomment-1595016095
PR Comment: https://git.openjdk.org/jdk/pull/14524#issuecomment-1595020596
PR Comment: https://git.openjdk.org/jdk/pull/14524#issuecomment-1595022380

From dcubed at openjdk.org  Fri Jun 16 17:42:12 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 16 Jun 2023 17:42:12 GMT
Subject: Integrated: 8310211:
 serviceability/jvmti/thread/GetStackTrace/getstacktr03/getstacktr03.java
 failing
In-Reply-To: <4-EbMiHgV6CKGswkciMMgncw2MLV3KAP3bTVudtWrVk=.945d6abf-3829-4723-bd1c-6e80a9204334@github.com>
References: <HUYxuELf38qqMME-4Wv5yrvU1Dg6QdxwbgyCi9uOpIQ=.33adeeb0-3a7f-4926-8c09-d8838b8396b6@github.com>
 <4-EbMiHgV6CKGswkciMMgncw2MLV3KAP3bTVudtWrVk=.945d6abf-3829-4723-bd1c-6e80a9204334@github.com>
Message-ID: <qjVeynrlIVBYMzKPDgZi2OfyS_t7WErYKi9eLFxqdow=.e54a25d9-9990-45a0-a25d-75f44f1dc7d7@github.com>

On Fri, 16 Jun 2023 17:26:38 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> A trivia fix for serviceability/jvmti/thread/GetStackTrace/getstacktr03/getstacktr03.java failing.
>
> Marked as reviewed by mikael (Reviewer).

@vidmik - Thanks for the review!

It appears that the bots are running very, very slow since my various pull request
commands have not yet all been processed... It's not being a quiet Friday at all...

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

PR Comment: https://git.openjdk.org/jdk/pull/14524#issuecomment-1595015175

From dcubed at openjdk.org  Fri Jun 16 17:42:12 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 16 Jun 2023 17:42:12 GMT
Subject: Integrated: 8310211:
 serviceability/jvmti/thread/GetStackTrace/getstacktr03/getstacktr03.java
 failing
In-Reply-To: <HUYxuELf38qqMME-4Wv5yrvU1Dg6QdxwbgyCi9uOpIQ=.33adeeb0-3a7f-4926-8c09-d8838b8396b6@github.com>
References: <HUYxuELf38qqMME-4Wv5yrvU1Dg6QdxwbgyCi9uOpIQ=.33adeeb0-3a7f-4926-8c09-d8838b8396b6@github.com>
Message-ID: <325lC2LYpGLcJe2-ZxSE1Xo_xap2JQJy3DJNEZtS2oU=.a7b657ff-6f32-4a0e-b666-a1d0673a8b60@github.com>

On Fri, 16 Jun 2023 17:10:08 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivia fix for serviceability/jvmti/thread/GetStackTrace/getstacktr03/getstacktr03.java failing.

This pull request has now been integrated.

Changeset: 16134f44
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/16134f44221e46f71d91fdba08e30705b0e1f92f
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8310211: serviceability/jvmti/thread/GetStackTrace/getstacktr03/getstacktr03.java failing

Co-authored-by: Alan Bateman <alanb at openjdk.org>
Reviewed-by: mikael

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

PR: https://git.openjdk.org/jdk/pull/14524

From cjplummer at openjdk.org  Fri Jun 16 18:14:09 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 16 Jun 2023 18:14:09 GMT
Subject: RFR: 8309979: BootstrapMethods attribute is missing in class files
 recreated by SA [v2]
In-Reply-To: <i3PjGx_wbQ63SlwcWL5eBr28sDUb1_dPQ8Q0P3Qgzds=.5f11a8e5-714c-45c0-87e6-e612bb50b28b@github.com>
References: <nSooA6CtKm8LsaxzYdqJ6mtVV0os-kT5F2xNvYI4lJo=.c27bd28e-88d3-4bcb-ac3d-9036140eeff0@github.com>
 <i3PjGx_wbQ63SlwcWL5eBr28sDUb1_dPQ8Q0P3Qgzds=.5f11a8e5-714c-45c0-87e6-e612bb50b28b@github.com>
Message-ID: <XMnH_cFQgCnx13I_1SqV-Br6T1QDwlbz9FzQZ-HlEaE=.f93bc591-726f-45fe-95ac-d1d6cfe79d06@github.com>

On Thu, 15 Jun 2023 20:24:39 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> Please review this PR that extends SA to write BootstrapMethods attribute when dumping the class files.
>> 
>> Tested it by dumping the class file for java/lang/String and comparing the BootstrapMethods attribute shown by javap for the original and the dumped class.
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments by plummercj
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

Yes, it is already problem listed. How did you run the tests? If you use "make test" it should be including the problem list automatically.

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

PR Comment: https://git.openjdk.org/jdk/pull/14495#issuecomment-1595083364

From duke at openjdk.org  Fri Jun 16 18:58:10 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Fri, 16 Jun 2023 18:58:10 GMT
Subject: RFR: 8309979: BootstrapMethods attribute is missing in class files
 recreated by SA [v2]
In-Reply-To: <i3PjGx_wbQ63SlwcWL5eBr28sDUb1_dPQ8Q0P3Qgzds=.5f11a8e5-714c-45c0-87e6-e612bb50b28b@github.com>
References: <nSooA6CtKm8LsaxzYdqJ6mtVV0os-kT5F2xNvYI4lJo=.c27bd28e-88d3-4bcb-ac3d-9036140eeff0@github.com>
 <i3PjGx_wbQ63SlwcWL5eBr28sDUb1_dPQ8Q0P3Qgzds=.5f11a8e5-714c-45c0-87e6-e612bb50b28b@github.com>
Message-ID: <TFH9TJr1w46b1fZHVEEuIDYgP2cBUJA8cS23hlWh8NA=.685e06f9-99b2-43f4-934c-fe035b95d35a@github.com>

On Thu, 15 Jun 2023 20:24:39 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> Please review this PR that extends SA to write BootstrapMethods attribute when dumping the class files.
>> 
>> Tested it by dumping the class file for java/lang/String and comparing the BootstrapMethods attribute shown by javap for the original and the dumped class.
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments by plummercj
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

I didn't run it through `make test`. I used `java -jar jtreg.jar <dir>`.

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

PR Comment: https://git.openjdk.org/jdk/pull/14495#issuecomment-1595145103

From cjplummer at openjdk.org  Fri Jun 16 19:09:08 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 16 Jun 2023 19:09:08 GMT
Subject: RFR: 8309605: StubRoutines are not used by SA [v2]
In-Reply-To: <1yxASjMq_kcHdxY_8uha1XJuXFUCi8psXXB_mUXLpog=.50d0ec59-e7c2-48d1-9d7e-57bd095829f1@github.com>
References: <DfeNDKoUQNaEY0Sbqyjp_k6Vwf8754zhsMwPAkCGrMA=.a9853b9e-4000-44df-8c63-7aa6b15d9b3d@github.com>
 <1yxASjMq_kcHdxY_8uha1XJuXFUCi8psXXB_mUXLpog=.50d0ec59-e7c2-48d1-9d7e-57bd095829f1@github.com>
Message-ID: <nebGz0W6iep2t-EFzbhf72GFwL-bI2RYf-9MMgfTb9E=.d020363a-25a4-4f29-928b-4370898d13a3@github.com>

On Fri, 16 Jun 2023 13:45:06 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please remove this trivial fix to remove StubRoutines that the SA doesn't use.
>> Tested serviceability/sa tests.
>
> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into stub-routines
>  - 8309605: StubRoutines are not used by SA

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14519#pullrequestreview-1484154205

From cjplummer at openjdk.org  Fri Jun 16 19:20:07 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 16 Jun 2023 19:20:07 GMT
Subject: RFR: JDK-8310191:
 com/sun/tools/attach/warnings/DynamicLoadWarningTest.java second failure on
 AIX [v2]
In-Reply-To: <ohZ5WzVwEneaGJsOOHcqchTZYZGDZkG5GgiAg_TkTO8=.b1a1c000-a575-49be-8815-f235b82365d4@github.com>
References: <w95pFP0nvGtt4jqpsO6hvX5LC1T4YZ19Qd8Z4uSsg1A=.58f39222-9e68-4ebf-8d9c-e68a2acaeaf6@github.com>
 <ohZ5WzVwEneaGJsOOHcqchTZYZGDZkG5GgiAg_TkTO8=.b1a1c000-a575-49be-8815-f235b82365d4@github.com>
Message-ID: <JcudCdXXi_3kxS6HbWvycMoct04ebI4J8sqyuzb_8sM=.86f8aafb-730e-4ac1-8d89-10a13b5a8253@github.com>

On Fri, 16 Jun 2023 11:59:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> After push of [JDK-8307478](https://bugs.openjdk.org/browse/JDK-8307478) , the following test started to fail on AIX :
>> com/sun/tools/attach/warnings/DynamicLoadWarningTest.java ; failure output :
>> 
>> java.lang.RuntimeException: 'WARNING: A JVM TI agent has been loaded dynamically' found in stderr
>> at jdk.test.lib.process.OutputAnalyzer.stderrShouldNotContain(OutputAnalyzer.java:320)
>> at DynamicLoadWarningTest$AppRunner.stderrShouldNotContain(DynamicLoadWarningTest.java:308)
>> at DynamicLoadWarningTest.testLoadOneJvmtiAgent(DynamicLoadWarningTest.java:138)
>> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
>> 
>> Should be handled in a similar way to [JDK-8309549](https://bugs.openjdk.org/browse/JDK-8309549) .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rearrange and simplify test coding

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14515#pullrequestreview-1484183655

From coleenp at openjdk.org  Fri Jun 16 20:07:16 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 16 Jun 2023 20:07:16 GMT
Subject: RFR: 8309605: StubRoutines are not used by SA [v2]
In-Reply-To: <1yxASjMq_kcHdxY_8uha1XJuXFUCi8psXXB_mUXLpog=.50d0ec59-e7c2-48d1-9d7e-57bd095829f1@github.com>
References: <DfeNDKoUQNaEY0Sbqyjp_k6Vwf8754zhsMwPAkCGrMA=.a9853b9e-4000-44df-8c63-7aa6b15d9b3d@github.com>
 <1yxASjMq_kcHdxY_8uha1XJuXFUCi8psXXB_mUXLpog=.50d0ec59-e7c2-48d1-9d7e-57bd095829f1@github.com>
Message-ID: <COaKHwTbQSL9sj8OJCbroLC0Y_Vw-mzTG7oWjk3QHnc=.4e0b4331-caaf-4609-a47f-7024ac4bdae1@github.com>

On Fri, 16 Jun 2023 13:45:06 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please remove this trivial fix to remove StubRoutines that the SA doesn't use.
>> Tested serviceability/sa tests.
>
> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into stub-routines
>  - 8309605: StubRoutines are not used by SA

Thanks Chris!

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

PR Comment: https://git.openjdk.org/jdk/pull/14519#issuecomment-1595235413

From coleenp at openjdk.org  Fri Jun 16 20:07:17 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 16 Jun 2023 20:07:17 GMT
Subject: Integrated: 8309605: StubRoutines are not used by SA
In-Reply-To: <DfeNDKoUQNaEY0Sbqyjp_k6Vwf8754zhsMwPAkCGrMA=.a9853b9e-4000-44df-8c63-7aa6b15d9b3d@github.com>
References: <DfeNDKoUQNaEY0Sbqyjp_k6Vwf8754zhsMwPAkCGrMA=.a9853b9e-4000-44df-8c63-7aa6b15d9b3d@github.com>
Message-ID: <jFn_gtGKCAyrVM0l3rr43kUdglWCDA8P4IPySxm96lw=.679c02ae-2dbd-4bdb-8488-9d291f2f1a36@github.com>

On Fri, 16 Jun 2023 13:28:26 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please remove this trivial fix to remove StubRoutines that the SA doesn't use.
> Tested serviceability/sa tests.

This pull request has now been integrated.

Changeset: 71baf00a
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/71baf00a2dce796f74b121d5ccd4ee9da167d806
Stats:     70 lines in 1 file changed: 0 ins; 69 del; 1 mod

8309605: StubRoutines are not used by SA

Reviewed-by: cjplummer

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

PR: https://git.openjdk.org/jdk/pull/14519

From dcubed at openjdk.org  Fri Jun 16 20:34:08 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 16 Jun 2023 20:34:08 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v2]
In-Reply-To: <XdYB_LK_u2E2ai0OiXTAZngiUyo0mkSV43XSQ95tAbM=.2accc74d-4765-4685-8f70-c683d93dbe25@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
 <XdYB_LK_u2E2ai0OiXTAZngiUyo0mkSV43XSQ95tAbM=.2accc74d-4765-4685-8f70-c683d93dbe25@github.com>
Message-ID: <EZxosZgN1fhUVv5Ra_jb3VdTPyxbjSRQq_rs06zk6mU=.fb3f46e7-7e63-40fd-b0d9-cf1f6ceb8a08@github.com>

On Fri, 16 Jun 2023 11:41:14 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The current implementation for testing generational ZGC with jtreg is implemented with a filter on the mode flag `ZGenerational`. Because of this only environments which set this flag explicitly will run most of the tests. 
>> So they get missed in Github Actions and for developers running jtreg locally without supplying the `ZGenerational` flag.
>> 
>> The proposed change here is to introduce two new jtreg requirement properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will effectively behave the same as the existing `vm.gc.<GC>` flags but also take the specific ZGC mode in account.
>> 
>> If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be true.
>> 
>> If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will also be true.
>> 
>> If `-XX:{+,-}ZGenerational` is supplied then either  `vm.gc.ZGenerational` or `vm.gc.ZSingelgen` be true depending on the flags value.
>> 
>> And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be false.
>> 
>> This change also splits the relevant tests into two distinct runs for the two modes. And the respective test ids are set to `ZGenerational` or `ZSinglegen` to make it easier to distinguish the runs.
>> 
>> This also solves the issue that some compiler tests will never run with generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the current filter `vm.opt.final.ZGenerational` requires the flag to be explicit, but these compiler tests uses `vm.flagless`. 
>> 
>> The introduction of  `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` harmonizes the way you specify generational / single gen ZGC test with the way it is done for other gcs with `vm.gc.<GC>`
>> 
>> To support this feature the Whitebox API is extended with `isDefaultVMFlag` to enable checking if `ZGenerational` is default or not.
>> 
>> `vm.opt.final.ZGenerational` is still kept because we still have some reasons to filter based on the supplied flags. 
>> - `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when running with ZGenerational
>> - `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with a different max heap size for ZGenerational, but it is not the intent to dispatch the test to both G1 and generational ZGC if Generational ZGC is not specified.  
>> 
>> `test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed to not filter but instead dispatch. However u...
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix wrong ZGenerational flag in VectorRebracket128Test.java

Hmmm... hopefully `vm.gc.ZSingelgen` is really `vm.gc.ZSinglegen`. If so you might
want to fix the PR description.

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

PR Comment: https://git.openjdk.org/jdk/pull/14509#issuecomment-1595274922

From naoto at openjdk.org  Fri Jun 16 21:02:17 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 16 Jun 2023 21:02:17 GMT
Subject: RFR: 8309632: JDK 21 RDP1 L10n resource files update [v2]
In-Reply-To: <m9PrVsggrFrkz3bYRVKXRBYTLpdjJjJgcqqAcw5p0UI=.5c786c31-5a91-4948-a415-4233a287a92c@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
 <m9PrVsggrFrkz3bYRVKXRBYTLpdjJjJgcqqAcw5p0UI=.5c786c31-5a91-4948-a415-4233a287a92c@github.com>
Message-ID: <Jfrbn9kav_htg9Xsi2K0qX_DMxUTs4QAEzMKI77gj-4=.089cfa89-dcf3-4441-817b-f6a575cb4d9c@github.com>

On Fri, 16 Jun 2023 04:39:42 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
>> 
>> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
>> 
>> For example,
>> 
>> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
>> 
>> 
>> Please note that the HTML files only apply to .properties, and not .java resources.
>
> Justin Lu has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Review: correct previous commit, remove ? as well
>  - Review: Remove ?? from 'javac.opt.Xlint.desc.output-file-clash' for zh_CN
>  - Review: Use old 'err.crash' zh_CN value
>  - Review: use Naoto's recommended ja values
>  - Revert 'main.help.opt.any.file' value for _de

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/11#pullrequestreview-1484380340

From jlu at openjdk.org  Fri Jun 16 21:14:20 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 16 Jun 2023 21:14:20 GMT
Subject: Integrated: 8309632: JDK 21 RDP1 L10n resource files update
In-Reply-To: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
References: <sYyanocjeAgE8oDBFf4jOCHrPrp38eC2g8KhEpD3PuI=.d950713d-2caa-4b46-91ab-b2a12bf3e4f8@github.com>
Message-ID: <yxBFAdo-tYodL8exo3y2xbRz6pYcTIvYVJ8Tnbzp1WM=.80ad659c-02ea-476d-8e2a-ed80b3187880@github.com>

On Mon, 12 Jun 2023 21:21:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the JDK's localized resources since the previous L10n translation drop (1/26).
> 
> To help with reviewing the changes, @jonathan-gibbons created a tool which displays the localized changes next to the original file's changes in UTF-8 native. Those files can be viewed [here](https://cr.openjdk.org/~jlu/output/) 
> 
> For example,
> 
> <img width="1081" alt="image" src="https://github.com/openjdk/jdk21/assets/67398801/e68a48a8-916e-4860-afb0-526924c6a3d3">
> 
> 
> Please note that the HTML files only apply to .properties, and not .java resources.

This pull request has now been integrated.

Changeset: a1c1d97a
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/a1c1d97a4e07bae872b5608b4d8d8f85195edd82
Stats:     460 lines in 50 files changed: 279 ins; 48 del; 133 mod

8309632: JDK 21 RDP1 L10n resource files update

Reviewed-by: naoto
Backport-of: 81bfd78901ff540ad0355a466cfad097e701028a

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

PR: https://git.openjdk.org/jdk21/pull/11

From amenkov at openjdk.org  Sat Jun 17 01:26:28 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Sat, 17 Jun 2023 01:26:28 GMT
Subject: RFR: JDK-8306441: Two-stage Segmented Heap Dump [v10]
In-Reply-To: <ZrfI7J1hP2Sekrm8mJwoCWbcz73iCuQc5WfyhmSOuz0=.558fad8d-019d-4552-bb0f-cbc4acc0c36c@github.com>
References: <8YqPPHSW4K1s0t317Kp6UqvoGuv5v9oCbjtQ9FX8p2o=.0f6c687b-d031-401d-901d-1ec532715cdc@github.com>
 <ZrfI7J1hP2Sekrm8mJwoCWbcz73iCuQc5WfyhmSOuz0=.558fad8d-019d-4552-bb0f-cbc4acc0c36c@github.com>
Message-ID: <HnBf-ZXHo1JcAunSKqAZqJk-gKQABGLbeluxWGfDQYo=.a436f5b9-183a-4685-8423-2acdf678908f@github.com>

On Wed, 14 Jun 2023 06:54:10 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> ### Motivation and proposal
>> Hi, heap dump brings about pauses for application's execution(STW), this is a well-known pain. JDK-8252842 have added parallel support to heapdump in an attempt to alleviate this issue. However, all concurrent threads competitively write heap data to the same file, and more memory is required to maintain the concurrent buffer queue. In experiments, we did not feel a significant performance improvement from that.
>> 
>> The minor-pause solution, which is presented in this PR, is a two-stage segmented heap dump:
>> 
>> 1. Stage One(STW): Concurrent threads directly write data to multiple heap files.
>> 2. Stage Two(Non-STW): Merge multiple heap files into one complete heap dump file.
>> 
>> Now concurrent worker threads are not required to maintain a buffer queue, which would result in more memory overhead, nor do they need to compete for locks. The changes in the overall design are as follows:
>> 
>> ![image](https://github.com/openjdk/jdk/assets/5010047/86d2717d-c621-446f-98c2-cce761ec8db5)
>> <p align="center">Fig1. Before</p>
>> 
>> ![image](https://github.com/openjdk/jdk/assets/5010047/c912c516-83b6-4343-a2e8-5d5bdb99cb87)
>> <p align="center">Fig1. After this patch</p>
>> 
>> ### Performance evaluation
>> | memory | numOfThread | STW         | Total      | Compression |
>> | --- | --------- | -------------- | ------------ | -------- |
>> | 8g | 1 thread | 15.612 secs | 15.612 secs | N |
>> | 8g | 32 thread |  2.5617250 secs | 14.498 secs | N |
>> | 8g | 32 thread | 2.3084878 secs | 3.198 secs | Compress1 |
>> | 8g | 32 thread | 10.9355128 secs | 21.882 secs | Compress2 |
>> | 8g | 96 thread | 2.6790452 secs | 14.012 secs | N |
>> | 8g | 96 thread | 2.3044796 secs | 3.589 secs | Compress1 |
>> | 8g | 96 thread | 9.7585151 secs | 20.219 secs| Compress2 |
>> | 16g | 1 thread | 26.278 secs | 26.278 secs | N |
>> | 16g | 32 thread |  5.2313740 secs | 26.417 secs | N |
>> | 16g | 32 thread | 5.6946983 secs | 6.538 secs | Compress1 |
>> | 16g | 32 thread | 21.8211105 secs | 41.133 secs | Compress2 |
>> | 16g | 96 thread | 6.2445556 secs | 27.141 secs | N |
>> | 16g | 96 thread | 4.6007096 secs | 6.259 secs | Compress1 |
>> | 16g | 96 thread | 19.2965783 secs |  39.007 secs | Compress2 |
>> | 32g | 1 thread | 48.149 secs | 48.149 secs | N |
>> | 32g | 32 thread | 10.7734677 secs | 61.643 secs | N |
>> | 32g | 32 thread | 10.1642097 secs | 10.903 secs | Compress1 |
>> | 32g | 32 thread | 43.8407607 secs | 88.152 secs | Compress2 |
>> | 32g | 96 thread | 13.1522042 ...
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   whitespace

Could you please add info about what testing have been done

src/hotspot/share/services/diagnosticCommand.cpp line 474:

> 472:   _overwrite("-overwrite", "If specified, the dump file will be overwritten if it exists",
> 473:            "BOOLEAN", false, "false"),
> 474:   _parallel("-parallel", "Number of parallel dump thread, it should be less than ParallelGCThread",

dump threadS.
Not sure it makes sense to mention ParallelGCThread (according to how the option is handled).
Maybe something like
"Number of parallel threads to use for heap dump. The VM will try to use the specified number of threads, but might use fewer."

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

PR Comment: https://git.openjdk.org/jdk/pull/13667#issuecomment-1595565123
PR Review Comment: https://git.openjdk.org/jdk/pull/13667#discussion_r1232892883

From amenkov at openjdk.org  Sat Jun 17 01:26:29 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Sat, 17 Jun 2023 01:26:29 GMT
Subject: RFR: JDK-8306441: Two-stage Segmented Heap Dump [v10]
In-Reply-To: <HnBf-ZXHo1JcAunSKqAZqJk-gKQABGLbeluxWGfDQYo=.a436f5b9-183a-4685-8423-2acdf678908f@github.com>
References: <8YqPPHSW4K1s0t317Kp6UqvoGuv5v9oCbjtQ9FX8p2o=.0f6c687b-d031-401d-901d-1ec532715cdc@github.com>
 <ZrfI7J1hP2Sekrm8mJwoCWbcz73iCuQc5WfyhmSOuz0=.558fad8d-019d-4552-bb0f-cbc4acc0c36c@github.com>
 <HnBf-ZXHo1JcAunSKqAZqJk-gKQABGLbeluxWGfDQYo=.a436f5b9-183a-4685-8423-2acdf678908f@github.com>
Message-ID: <Cay8Gl-drH2oGqQaQ4JD66Q7wAmom1zfx5BKbzOLetc=.27c38b04-52db-43cf-aa64-7c9eef96c7a8@github.com>

On Sat, 17 Jun 2023 00:22:09 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   whitespace
>
> src/hotspot/share/services/diagnosticCommand.cpp line 474:
> 
>> 472:   _overwrite("-overwrite", "If specified, the dump file will be overwritten if it exists",
>> 473:            "BOOLEAN", false, "false"),
>> 474:   _parallel("-parallel", "Number of parallel dump thread, it should be less than ParallelGCThread",
> 
> dump threadS.
> Not sure it makes sense to mention ParallelGCThread (according to how the option is handled).
> Maybe something like
> "Number of parallel threads to use for heap dump. The VM will try to use the specified number of threads, but might use fewer."

This change adds new option. most likely this requires CSR

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13667#discussion_r1232922184

From alanb at openjdk.org  Sat Jun 17 13:27:07 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 17 Jun 2023 13:27:07 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v2]
In-Reply-To: <XdYB_LK_u2E2ai0OiXTAZngiUyo0mkSV43XSQ95tAbM=.2accc74d-4765-4685-8f70-c683d93dbe25@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
 <XdYB_LK_u2E2ai0OiXTAZngiUyo0mkSV43XSQ95tAbM=.2accc74d-4765-4685-8f70-c683d93dbe25@github.com>
Message-ID: <UacoN1UkjzQneZXHN7C6Zksv8zKj3gnGEeuVyrbyy8w=.1448f532-eb31-4172-816f-dc98da587b23@github.com>

On Fri, 16 Jun 2023 11:41:14 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The current implementation for testing generational ZGC with jtreg is implemented with a filter on the mode flag `ZGenerational`. Because of this only environments which set this flag explicitly will run most of the tests. 
>> So they get missed in Github Actions and for developers running jtreg locally without supplying the `ZGenerational` flag.
>> 
>> The proposed change here is to introduce two new jtreg requirement properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will effectively behave the same as the existing `vm.gc.<GC>` flags but also take the specific ZGC mode in account.
>> 
>> If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be true.
>> 
>> If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will also be true.
>> 
>> If `-XX:{+,-}ZGenerational` is supplied then either  `vm.gc.ZGenerational` or `vm.gc.ZSingelgen` be true depending on the flags value.
>> 
>> And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be false.
>> 
>> This change also splits the relevant tests into two distinct runs for the two modes. And the respective test ids are set to `ZGenerational` or `ZSinglegen` to make it easier to distinguish the runs.
>> 
>> This also solves the issue that some compiler tests will never run with generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the current filter `vm.opt.final.ZGenerational` requires the flag to be explicit, but these compiler tests uses `vm.flagless`. 
>> 
>> The introduction of  `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` harmonizes the way you specify generational / single gen ZGC test with the way it is done for other gcs with `vm.gc.<GC>`
>> 
>> To support this feature the Whitebox API is extended with `isDefaultVMFlag` to enable checking if `ZGenerational` is default or not.
>> 
>> `vm.opt.final.ZGenerational` is still kept because we still have some reasons to filter based on the supplied flags. 
>> - `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when running with ZGenerational
>> - `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with a different max heap size for ZGenerational, but it is not the intent to dispatch the test to both G1 and generational ZGC if Generational ZGC is not specified.  
>> 
>> `test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed to not filter but instead dispatch. However u...
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix wrong ZGenerational flag in VectorRebracket128Test.java

test/jdk/java/lang/Thread/virtual/stress/Skynet.java line 25:

> 23: 
> 24: /*
> 25:  * @test

Would you mind adding "id=default" to this test? If a test has several `@test` tags, some with an identifier, and some without, then it can be tricky to understand test selection and exclusion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14509#discussion_r1233062199

From dholmes at openjdk.org  Mon Jun 19 00:51:30 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 19 Jun 2023 00:51:30 GMT
Subject: RFR: 8303916: ThreadLists.java inconsistent results
In-Reply-To: <YWEgolCKkAFKry4d_j0ww7-uq9CFnxU4wR7ZIPgReAk=.59568ea5-da11-4471-a1ba-78d7a0d43adb@github.com>
References: <H3WNK3qa7r4NXwPkjzAo8kIgus6c9VedG5F64t0plH8=.762a0531-40da-4f1c-8ba2-acd278417e30@github.com>
 <YWEgolCKkAFKry4d_j0ww7-uq9CFnxU4wR7ZIPgReAk=.59568ea5-da11-4471-a1ba-78d7a0d43adb@github.com>
Message-ID: <OT6z6wtiB40PwbFI5ou5VbriD6FdQSnOKg-Q0ts8FPI=.0f7feb46-7574-4bea-b1b6-37ba93f84709@github.com>

On Thu, 15 Jun 2023 09:17:24 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> I did look at the history and this test exists because of previous confusion about thread groups, where the top thread group and the MXBean thread lists could be different. So if this test creates new threads and checks they are in both lists, it loses the original purpose as I read it.

Can you elaborate what the issue was please. I would have to suspect the wrong "top" ThreadGroup was being used (main vs. system).

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

PR Comment: https://git.openjdk.org/jdk/pull/14465#issuecomment-1596332757

From yyang at openjdk.org  Mon Jun 19 02:02:10 2023
From: yyang at openjdk.org (Yi Yang)
Date: Mon, 19 Jun 2023 02:02:10 GMT
Subject: RFR: JDK-8306441: Two-stage Segmented Heap Dump [v10]
In-Reply-To: <Cay8Gl-drH2oGqQaQ4JD66Q7wAmom1zfx5BKbzOLetc=.27c38b04-52db-43cf-aa64-7c9eef96c7a8@github.com>
References: <8YqPPHSW4K1s0t317Kp6UqvoGuv5v9oCbjtQ9FX8p2o=.0f6c687b-d031-401d-901d-1ec532715cdc@github.com>
 <ZrfI7J1hP2Sekrm8mJwoCWbcz73iCuQc5WfyhmSOuz0=.558fad8d-019d-4552-bb0f-cbc4acc0c36c@github.com>
 <HnBf-ZXHo1JcAunSKqAZqJk-gKQABGLbeluxWGfDQYo=.a436f5b9-183a-4685-8423-2acdf678908f@github.com>
 <Cay8Gl-drH2oGqQaQ4JD66Q7wAmom1zfx5BKbzOLetc=.27c38b04-52db-43cf-aa64-7c9eef96c7a8@github.com>
Message-ID: <jkYEJfq5vwf5YQpENc8As83pr_y1z6104tJriy96iBk=.2e6e4dc7-9020-4dee-8157-9f613d744484@github.com>

On Sat, 17 Jun 2023 01:22:54 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> This change adds new option. most likely this requires CSR

Hi @alexmenkov, it seems that adding new parameters to jcmd does not require a CSR, only changes like those to jmap do.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13667#discussion_r1233444531

From mbaesken at openjdk.org  Mon Jun 19 06:43:15 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 19 Jun 2023 06:43:15 GMT
Subject: Integrated: JDK-8310191:
 com/sun/tools/attach/warnings/DynamicLoadWarningTest.java second failure on
 AIX
In-Reply-To: <w95pFP0nvGtt4jqpsO6hvX5LC1T4YZ19Qd8Z4uSsg1A=.58f39222-9e68-4ebf-8d9c-e68a2acaeaf6@github.com>
References: <w95pFP0nvGtt4jqpsO6hvX5LC1T4YZ19Qd8Z4uSsg1A=.58f39222-9e68-4ebf-8d9c-e68a2acaeaf6@github.com>
Message-ID: <rIWndjJ0nSG-S99Gfd_rBoR5ZlsDnDWr5f6ok4v5YlI=.c431b8c9-2c26-40df-9335-7db7fc089f9e@github.com>

On Fri, 16 Jun 2023 10:44:47 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> After push of [JDK-8307478](https://bugs.openjdk.org/browse/JDK-8307478) , the following test started to fail on AIX :
> com/sun/tools/attach/warnings/DynamicLoadWarningTest.java ; failure output :
> 
> java.lang.RuntimeException: 'WARNING: A JVM TI agent has been loaded dynamically' found in stderr
> at jdk.test.lib.process.OutputAnalyzer.stderrShouldNotContain(OutputAnalyzer.java:320)
> at DynamicLoadWarningTest$AppRunner.stderrShouldNotContain(DynamicLoadWarningTest.java:308)
> at DynamicLoadWarningTest.testLoadOneJvmtiAgent(DynamicLoadWarningTest.java:138)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> 
> Should be handled in a similar way to [JDK-8309549](https://bugs.openjdk.org/browse/JDK-8309549) .

This pull request has now been integrated.

Changeset: 6a63badd
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6a63badd8ea3e79cd9fc3cb33aff499fc9a6d3f1
Stats:     20 lines in 1 file changed: 8 ins; 8 del; 4 mod

8310191: com/sun/tools/attach/warnings/DynamicLoadWarningTest.java second failure on AIX

Reviewed-by: alanb, cjplummer

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

PR: https://git.openjdk.org/jdk/pull/14515

From aboldtch at openjdk.org  Mon Jun 19 06:55:52 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 19 Jun 2023 06:55:52 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v3]
In-Reply-To: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
Message-ID: <3yy4WQIDq7tTBt53suFujkDg7UK2cR8gllrNnWHBLgY=.280e5138-a3c0-4bbe-874f-572a1c30638e@github.com>

> The current implementation for testing generational ZGC with jtreg is implemented with a filter on the mode flag `ZGenerational`. Because of this only environments which set this flag explicitly will run most of the tests. 
> So they get missed in Github Actions and for developers running jtreg locally without supplying the `ZGenerational` flag.
> 
> The proposed change here is to introduce two new jtreg requirement properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will effectively behave the same as the existing `vm.gc.<GC>` flags but also take the specific ZGC mode in account.
> 
> If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be true.
> 
> If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will also be true.
> 
> If `-XX:{+,-}ZGenerational` is supplied then either  `vm.gc.ZGenerational` or `vm.gc.ZSingelgen` be true depending on the flags value.
> 
> And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be false.
> 
> This change also splits the relevant tests into two distinct runs for the two modes. And the respective test ids are set to `ZGenerational` or `ZSinglegen` to make it easier to distinguish the runs.
> 
> This also solves the issue that some compiler tests will never run with generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the current filter `vm.opt.final.ZGenerational` requires the flag to be explicit, but these compiler tests uses `vm.flagless`. 
> 
> The introduction of  `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` harmonizes the way you specify generational / single gen ZGC test with the way it is done for other gcs with `vm.gc.<GC>`
> 
> To support this feature the Whitebox API is extended with `isDefaultVMFlag` to enable checking if `ZGenerational` is default or not.
> 
> `vm.opt.final.ZGenerational` is still kept because we still have some reasons to filter based on the supplied flags. 
> - `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when running with ZGenerational
> - `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with a different max heap size for ZGenerational, but it is not the intent to dispatch the test to both G1 and generational ZGC if Generational ZGC is not specified.  
> 
> `test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed to not filter but instead dispatch. However unsure if this change should be included. The change ...

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Add explicit id to all Skynet.java @test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14509/files
  - new: https://git.openjdk.org/jdk/pull/14509/files/e571b87f..b262d48b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14509&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14509&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14509.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14509/head:pull/14509

PR: https://git.openjdk.org/jdk/pull/14509

From yyang at openjdk.org  Mon Jun 19 07:00:42 2023
From: yyang at openjdk.org (Yi Yang)
Date: Mon, 19 Jun 2023 07:00:42 GMT
Subject: RFR: JDK-8306441: Two-stage Segmented Heap Dump [v11]
In-Reply-To: <8YqPPHSW4K1s0t317Kp6UqvoGuv5v9oCbjtQ9FX8p2o=.0f6c687b-d031-401d-901d-1ec532715cdc@github.com>
References: <8YqPPHSW4K1s0t317Kp6UqvoGuv5v9oCbjtQ9FX8p2o=.0f6c687b-d031-401d-901d-1ec532715cdc@github.com>
Message-ID: <3rWqmrrY8qDPQjrVolTTnDckeqVuKvHay7Ip9SxgEfc=.79ec3883-7bed-4c27-a89b-62199d9849bc@github.com>

> ### Motivation and proposal
> Hi, heap dump brings about pauses for application's execution(STW), this is a well-known pain. JDK-8252842 have added parallel support to heapdump in an attempt to alleviate this issue. However, all concurrent threads competitively write heap data to the same file, and more memory is required to maintain the concurrent buffer queue. In experiments, we did not feel a significant performance improvement from that.
> 
> The minor-pause solution, which is presented in this PR, is a two-stage segmented heap dump:
> 
> 1. Stage One(STW): Concurrent threads directly write data to multiple heap files.
> 2. Stage Two(Non-STW): Merge multiple heap files into one complete heap dump file.
> 
> Now concurrent worker threads are not required to maintain a buffer queue, which would result in more memory overhead, nor do they need to compete for locks. The changes in the overall design are as follows:
> 
> ![image](https://github.com/openjdk/jdk/assets/5010047/86d2717d-c621-446f-98c2-cce761ec8db5)
> <p align="center">Fig1. Before</p>
> 
> ![image](https://github.com/openjdk/jdk/assets/5010047/c912c516-83b6-4343-a2e8-5d5bdb99cb87)
> <p align="center">Fig1. After this patch</p>
> 
> ### Performance evaluation
> | memory | numOfThread | STW         | Total      | Compression |
> | --- | --------- | -------------- | ------------ | -------- |
> | 8g | 1 thread | 15.612 secs | 15.612 secs | N |
> | 8g | 32 thread |  2.5617250 secs | 14.498 secs | N |
> | 8g | 32 thread | 2.3084878 secs | 3.198 secs | Compress1 |
> | 8g | 32 thread | 10.9355128 secs | 21.882 secs | Compress2 |
> | 8g | 96 thread | 2.6790452 secs | 14.012 secs | N |
> | 8g | 96 thread | 2.3044796 secs | 3.589 secs | Compress1 |
> | 8g | 96 thread | 9.7585151 secs | 20.219 secs| Compress2 |
> | 16g | 1 thread | 26.278 secs | 26.278 secs | N |
> | 16g | 32 thread |  5.2313740 secs | 26.417 secs | N |
> | 16g | 32 thread | 5.6946983 secs | 6.538 secs | Compress1 |
> | 16g | 32 thread | 21.8211105 secs | 41.133 secs | Compress2 |
> | 16g | 96 thread | 6.2445556 secs | 27.141 secs | N |
> | 16g | 96 thread | 4.6007096 secs | 6.259 secs | Compress1 |
> | 16g | 96 thread | 19.2965783 secs |  39.007 secs | Compress2 |
> | 32g | 1 thread | 48.149 secs | 48.149 secs | N |
> | 32g | 32 thread | 10.7734677 secs | 61.643 secs | N |
> | 32g | 32 thread | 10.1642097 secs | 10.903 secs | Compress1 |
> | 32g | 32 thread | 43.8407607 secs | 88.152 secs | Compress2 |
> | 32g | 96 thread | 13.1522042 secs | 61.432 secs | N |
> | 32g | 96 thread | 9.0954641 secs | 9.885 secs | C...

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  perform merging by attach listener thread where possible

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13667/files
  - new: https://git.openjdk.org/jdk/pull/13667/files/2280159a..e1328f06

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13667&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13667&range=09-10

  Stats: 61 lines in 5 files changed: 41 ins; 2 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/13667.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13667/head:pull/13667

PR: https://git.openjdk.org/jdk/pull/13667

From yyang at openjdk.org  Mon Jun 19 07:00:43 2023
From: yyang at openjdk.org (Yi Yang)
Date: Mon, 19 Jun 2023 07:00:43 GMT
Subject: RFR: JDK-8306441: Two-stage Segmented Heap Dump [v10]
In-Reply-To: <HnBf-ZXHo1JcAunSKqAZqJk-gKQABGLbeluxWGfDQYo=.a436f5b9-183a-4685-8423-2acdf678908f@github.com>
References: <8YqPPHSW4K1s0t317Kp6UqvoGuv5v9oCbjtQ9FX8p2o=.0f6c687b-d031-401d-901d-1ec532715cdc@github.com>
 <ZrfI7J1hP2Sekrm8mJwoCWbcz73iCuQc5WfyhmSOuz0=.558fad8d-019d-4552-bb0f-cbc4acc0c36c@github.com>
 <HnBf-ZXHo1JcAunSKqAZqJk-gKQABGLbeluxWGfDQYo=.a436f5b9-183a-4685-8423-2acdf678908f@github.com>
Message-ID: <xUq9EEUm0s7zRzcR31v7PNj0iCQANrQp8qQKzl8AtcM=.af5c217a-597b-4f9c-82b1-b8ad080c9f8c@github.com>

On Sat, 17 Jun 2023 01:20:21 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   whitespace
>
> Could you please add info about what testing have been done

Hi @alexmenkov,

> Could you please add info about what testing have been done

Including serviceability tests and manual checks for both slowdebug and release version.  I'll do more test and sync test result in the main content of this PR.

I push a new commit to optimize the merge stage.  Now it performs heapdump file merge operation in attach listener thread when possible, which prevents us from occupying the VM Thread, which in turn affects the occurrence of GC and other VM operations.

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

PR Comment: https://git.openjdk.org/jdk/pull/13667#issuecomment-1596609826

From aboldtch at openjdk.org  Mon Jun 19 07:03:09 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 19 Jun 2023 07:03:09 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v2]
In-Reply-To: <UacoN1UkjzQneZXHN7C6Zksv8zKj3gnGEeuVyrbyy8w=.1448f532-eb31-4172-816f-dc98da587b23@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
 <XdYB_LK_u2E2ai0OiXTAZngiUyo0mkSV43XSQ95tAbM=.2accc74d-4765-4685-8f70-c683d93dbe25@github.com>
 <UacoN1UkjzQneZXHN7C6Zksv8zKj3gnGEeuVyrbyy8w=.1448f532-eb31-4172-816f-dc98da587b23@github.com>
Message-ID: <GBrJ84po6uCENIHrklbo2U9V89wEkmsL08bJIqPa4Ho=.120247b1-d582-4dbc-b6e7-264a3fb4b463@github.com>

On Sat, 17 Jun 2023 13:24:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix wrong ZGenerational flag in VectorRebracket128Test.java
>
> test/jdk/java/lang/Thread/virtual/stress/Skynet.java line 25:
> 
>> 23: 
>> 24: /*
>> 25:  * @test
> 
> Would you mind adding "id=default" to this test? If a test has several `@test` tags, some with an identifier, and some without, then it can be tricky to understand test selection and exclusion.

Done. 

I tried to reduce changes to other ids as much as possible as they may be used for problemlisting etc. The first run would have been `#id0` before and after this patch. However does not seem to be any exclusion filters in the repo for Skynet so added a default id. 

Because this patch adds extra `@test` some `#idX` will change. I've tried to double check that there are no problemlistings that depend on this, and I can find none. 

Ideally all multi `@test` tests should use explicit ids so changing that updating existing tests is less fragile with respect to exclusions. However I know that there are more gotchas here with how problemlisting works. Not sure I remember the exact details but I believe that under certain circumstances the id will be ignored, and if a problemlisting includes it, it will not filter it out. 

For now updating tests will always require going through all relevant problemlisting files and check that the exclusions are still valid.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14509#discussion_r1233609799

From aboldtch at openjdk.org  Mon Jun 19 07:09:09 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 19 Jun 2023 07:09:09 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v2]
In-Reply-To: <EZxosZgN1fhUVv5Ra_jb3VdTPyxbjSRQq_rs06zk6mU=.fb3f46e7-7e63-40fd-b0d9-cf1f6ceb8a08@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
 <XdYB_LK_u2E2ai0OiXTAZngiUyo0mkSV43XSQ95tAbM=.2accc74d-4765-4685-8f70-c683d93dbe25@github.com>
 <EZxosZgN1fhUVv5Ra_jb3VdTPyxbjSRQq_rs06zk6mU=.fb3f46e7-7e63-40fd-b0d9-cf1f6ceb8a08@github.com>
Message-ID: <0KZm7_X6hq4s6ujXEtDPQi0i1JCXD0XzSI4Toq5ZVCs=.f66591e3-a20f-4e45-a2cc-107535626706@github.com>

On Fri, 16 Jun 2023 20:31:28 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Hmmm... hopefully `vm.gc.ZSingelgen` is really `vm.gc.ZSinglegen`. If so you might want to fix the PR description.

What part are you worried about? When would `vm.gc.ZSingelgen` be invalid? 

Also what part of the PR requires fixing?

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

PR Comment: https://git.openjdk.org/jdk/pull/14509#issuecomment-1596626922

From alanb at openjdk.org  Mon Jun 19 07:23:09 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 19 Jun 2023 07:23:09 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v2]
In-Reply-To: <0KZm7_X6hq4s6ujXEtDPQi0i1JCXD0XzSI4Toq5ZVCs=.f66591e3-a20f-4e45-a2cc-107535626706@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
 <XdYB_LK_u2E2ai0OiXTAZngiUyo0mkSV43XSQ95tAbM=.2accc74d-4765-4685-8f70-c683d93dbe25@github.com>
 <EZxosZgN1fhUVv5Ra_jb3VdTPyxbjSRQq_rs06zk6mU=.fb3f46e7-7e63-40fd-b0d9-cf1f6ceb8a08@github.com>
 <0KZm7_X6hq4s6ujXEtDPQi0i1JCXD0XzSI4Toq5ZVCs=.f66591e3-a20f-4e45-a2cc-107535626706@github.com>
Message-ID: <06Ia9w1yf91JRYaIMQAdbwKymzljIA_6mdAO22L9OYo=.f70ab943-832e-4018-ab2b-973f90f6d2b9@github.com>

On Mon, 19 Jun 2023 07:06:00 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> > Hmmm... hopefully `vm.gc.ZSingelgen` is really `vm.gc.ZSinglegen`. If so you might want to fix the PR description.
> 
> What part are you worried about? When would `vm.gc.ZSingelgen` be invalid?
> 
> Also what part of the PR requires fixing?

I assume Dan is pointing out the typo in the PR description ("e" and "l" have been transposed).

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

PR Comment: https://git.openjdk.org/jdk/pull/14509#issuecomment-1596645899

From stuefe at openjdk.org  Mon Jun 19 09:07:11 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 19 Jun 2023 09:07:11 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v3]
In-Reply-To: <3yy4WQIDq7tTBt53suFujkDg7UK2cR8gllrNnWHBLgY=.280e5138-a3c0-4bbe-874f-572a1c30638e@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
 <3yy4WQIDq7tTBt53suFujkDg7UK2cR8gllrNnWHBLgY=.280e5138-a3c0-4bbe-874f-572a1c30638e@github.com>
Message-ID: <Y0_ibTPlMn3qi6kp4Yiq5UgiiAabHFZMYtg9MxkUI4Q=.1609fbef-0242-4cd8-b93f-e2feeeb7ff96@github.com>

On Mon, 19 Jun 2023 06:55:52 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The current implementation for testing generational ZGC with jtreg is implemented with a filter on the mode flag `ZGenerational`. Because of this only environments which set this flag explicitly will run most of the tests. 
>> So they get missed in Github Actions and for developers running jtreg locally without supplying the `ZGenerational` flag.
>> 
>> The proposed change here is to introduce two new jtreg requirement properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will effectively behave the same as the existing `vm.gc.<GC>` flags but also take the specific ZGC mode in account.
>> 
>> If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will be true.
>> 
>> If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will also be true.
>> 
>> If `-XX:{+,-}ZGenerational` is supplied then either  `vm.gc.ZGenerational` or `vm.gc.ZSinglegen` be true depending on the flags value.
>> 
>> And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will be false.
>> 
>> This change also splits the relevant tests into two distinct runs for the two modes. And the respective test ids are set to `ZGenerational` or `ZSinglegen` to make it easier to distinguish the runs.
>> 
>> This also solves the issue that some compiler tests will never run with generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the current filter `vm.opt.final.ZGenerational` requires the flag to be explicit, but these compiler tests uses `vm.flagless`. 
>> 
>> The introduction of  `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` harmonizes the way you specify generational / single gen ZGC test with the way it is done for other gcs with `vm.gc.<GC>`
>> 
>> To support this feature the Whitebox API is extended with `isDefaultVMFlag` to enable checking if `ZGenerational` is default or not.
>> 
>> `vm.opt.final.ZGenerational` is still kept because we still have some reasons to filter based on the supplied flags. 
>> - `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when running with ZGenerational
>> - `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with a different max heap size for ZGenerational, but it is not the intent to dispatch the test to both G1 and generational ZGC if Generational ZGC is not specified.  
>> 
>> `test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed to not filter but instead dispatch. However u...
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add explicit id to all Skynet.java @test

I'm not the most qualified for ZGC, but I looked this over with a mind on the planned 21 backport. I wanted to check if any of the existing legacy ZGC tests had been changed, either accidentally or deliberately. This seems not be the case.

The remarks are small nits, feel free to ignore them.

How much time do we spend now in GHAs on the additional Zgenerational tests? In any case, this makes sense.

Cheers, Thomas

test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationTools.java line 298:

> 296:         if (selectedGCMode != null) {
> 297:             args.add(selectedGCMode);
> 298:         }

just to be sure, maybe add a "must not be Z" assert in the else path?

test/hotspot/jtreg/runtime/cds/appcds/TestZGCWithCDS.java line 58:

> 56:     public final static String ERR_MSG = "The saved state of UseCompressedOops and UseCompressedClassPointers is different from runtime, CDS will be disabled.";
> 57:     public static void main(String... args) throws Exception {
> 58:          String zGenerational = args[0];

assert not null?

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14509#pullrequestreview-1485730970
PR Review Comment: https://git.openjdk.org/jdk/pull/14509#discussion_r1233738199
PR Review Comment: https://git.openjdk.org/jdk/pull/14509#discussion_r1233740188

From kevinw at openjdk.org  Mon Jun 19 09:07:16 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 19 Jun 2023 09:07:16 GMT
Subject: RFR: 8303916: ThreadLists.java inconsistent results
In-Reply-To: <H3WNK3qa7r4NXwPkjzAo8kIgus6c9VedG5F64t0plH8=.762a0531-40da-4f1c-8ba2-acd278417e30@github.com>
References: <H3WNK3qa7r4NXwPkjzAo8kIgus6c9VedG5F64t0plH8=.762a0531-40da-4f1c-8ba2-acd278417e30@github.com>
Message-ID: <QIDB06zxXW6NfEZAhwFb1WI1EAlOWGnlD1cFnOiJU50=.399b99ac-15f9-45e8-b091-fa7dd97b40cc@github.com>

On Wed, 14 Jun 2023 09:30:49 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test fails when additional threads are created, as it compares thread lists from different sources and sees a mismatch.
> 
> It needs to tolerate some threads with certain names appearing, e.g. JVMCI and ForkJoin threads.  If there are extra threads in the thread ID list from the ThreadMBean, remove them from the thread count before comparing.
> 
> When it fails, additionally print the ids and names of threads that it got from the MBean.
> 
> I found the test quite confusing, the naming of thread counts, arrays of threads, and arrays of thread stacktraces from different sources, so have renamed some things.

> 

Sure, this was:

5047639: threadGroup.enumerate() ignores the Signal Dispatcher thread
https://bugs.openjdk.org/browse/JDK-5047639
(2004)

top ThreadGroup enumerate returns one less thread than ThreadMBean's getThreadCount.

Notes: SignalDispatcher started by the VM, question on whether ThreadMBean should include system threads.
Threads only added to a group if started with Thread.start()



The test wants to ensure that thread group and mbean are consistent, it doesn't particularly look for any thread belonging to a particular group, but would be happy as long as all threads are either in both samples or neither.

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

PR Comment: https://git.openjdk.org/jdk/pull/14465#issuecomment-1596798164

From yyang at openjdk.org  Mon Jun 19 09:23:31 2023
From: yyang at openjdk.org (Yi Yang)
Date: Mon, 19 Jun 2023 09:23:31 GMT
Subject: RFR: JDK-8306441: Two-stage Segmented Heap Dump [v12]
In-Reply-To: <8YqPPHSW4K1s0t317Kp6UqvoGuv5v9oCbjtQ9FX8p2o=.0f6c687b-d031-401d-901d-1ec532715cdc@github.com>
References: <8YqPPHSW4K1s0t317Kp6UqvoGuv5v9oCbjtQ9FX8p2o=.0f6c687b-d031-401d-901d-1ec532715cdc@github.com>
Message-ID: <83kaW-q8PmlLsKpyBZ45_hch5R_-kIKUzEoJtw2zxgM=.78fb2ed3-f2ea-4c9f-a080-e1eccce01d17@github.com>

> ### Motivation and proposal
> Hi, heap dump brings about pauses for application's execution(STW), this is a well-known pain. JDK-8252842 have added parallel support to heapdump in an attempt to alleviate this issue. However, all concurrent threads competitively write heap data to the same file, and more memory is required to maintain the concurrent buffer queue. In experiments, we did not feel a significant performance improvement from that.
> 
> The minor-pause solution, which is presented in this PR, is a two-stage segmented heap dump:
> 
> 1. Stage One(STW): Concurrent threads directly write data to multiple heap files.
> 2. Stage Two(Non-STW): Merge multiple heap files into one complete heap dump file.
> 
> Now concurrent worker threads are not required to maintain a buffer queue, which would result in more memory overhead, nor do they need to compete for locks. The changes in the overall design are as follows:
> 
> ![image](https://github.com/openjdk/jdk/assets/5010047/86d2717d-c621-446f-98c2-cce761ec8db5)
> <p align="center">Fig1. Before</p>
> 
> ![image](https://github.com/openjdk/jdk/assets/5010047/c912c516-83b6-4343-a2e8-5d5bdb99cb87)
> <p align="center">Fig1. After this patch</p>
> 
> ### Performance evaluation
> | memory | numOfThread | STW         | Total      | Compression |
> | --- | --------- | -------------- | ------------ | -------- |
> | 8g | 1 thread | 15.612 secs | 15.612 secs | N |
> | 8g | 32 thread |  2.5617250 secs | 14.498 secs | N |
> | 8g | 32 thread | 2.3084878 secs | 3.198 secs | Compress1 |
> | 8g | 32 thread | 10.9355128 secs | 21.882 secs | Compress2 |
> | 8g | 96 thread | 2.6790452 secs | 14.012 secs | N |
> | 8g | 96 thread | 2.3044796 secs | 3.589 secs | Compress1 |
> | 8g | 96 thread | 9.7585151 secs | 20.219 secs| Compress2 |
> | 16g | 1 thread | 26.278 secs | 26.278 secs | N |
> | 16g | 32 thread |  5.2313740 secs | 26.417 secs | N |
> | 16g | 32 thread | 5.6946983 secs | 6.538 secs | Compress1 |
> | 16g | 32 thread | 21.8211105 secs | 41.133 secs | Compress2 |
> | 16g | 96 thread | 6.2445556 secs | 27.141 secs | N |
> | 16g | 96 thread | 4.6007096 secs | 6.259 secs | Compress1 |
> | 16g | 96 thread | 19.2965783 secs |  39.007 secs | Compress2 |
> | 32g | 1 thread | 48.149 secs | 48.149 secs | N |
> | 32g | 32 thread | 10.7734677 secs | 61.643 secs | N |
> | 32g | 32 thread | 10.1642097 secs | 10.903 secs | Compress1 |
> | 32g | 32 thread | 43.8407607 secs | 88.152 secs | Compress2 |
> | 32g | 96 thread | 13.1522042 secs | 61.432 secs | N |
> | 32g | 96 thread | 9.0954641 secs | 9.885 secs | C...

Yi Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Merge branch 'master' of github.com:openjdk/jdk into merge_dump_public
 - use HandshakeClosure instead of VMOperation
 - perform merging by attach listener thread where possible
 - whitespace
 - review from Alex
 - undo refactor -- done
 - undo refactor
 - rename back to heapdumpCompression
 - execute VM_HeapDumper directly
 - remove useless scope
 - ... and 4 more: https://git.openjdk.org/jdk/compare/d2a858e1...02561629

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

Changes: https://git.openjdk.org/jdk/pull/13667/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13667&range=11
  Stats: 1269 lines in 10 files changed: 216 ins; 932 del; 121 mod
  Patch: https://git.openjdk.org/jdk/pull/13667.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13667/head:pull/13667

PR: https://git.openjdk.org/jdk/pull/13667

From yyang at openjdk.org  Mon Jun 19 09:50:28 2023
From: yyang at openjdk.org (Yi Yang)
Date: Mon, 19 Jun 2023 09:50:28 GMT
Subject: RFR: JDK-8306441: Two-stage Segmented Heap Dump [v13]
In-Reply-To: <8YqPPHSW4K1s0t317Kp6UqvoGuv5v9oCbjtQ9FX8p2o=.0f6c687b-d031-401d-901d-1ec532715cdc@github.com>
References: <8YqPPHSW4K1s0t317Kp6UqvoGuv5v9oCbjtQ9FX8p2o=.0f6c687b-d031-401d-901d-1ec532715cdc@github.com>
Message-ID: <d-bI-es_zNgLBL6kwaOINQ4oEtRgcijR7mMv0jKIlFA=.662219ed-007c-41e6-9380-f2577826d1cb@github.com>

> ### Motivation and proposal
> Hi, heap dump brings about pauses for application's execution(STW), this is a well-known pain. JDK-8252842 have added parallel support to heapdump in an attempt to alleviate this issue. However, all concurrent threads competitively write heap data to the same file, and more memory is required to maintain the concurrent buffer queue. In experiments, we did not feel a significant performance improvement from that.
> 
> The minor-pause solution, which is presented in this PR, is a two-stage segmented heap dump:
> 
> 1. Stage One(STW): Concurrent threads directly write data to multiple heap files.
> 2. Stage Two(Non-STW): Merge multiple heap files into one complete heap dump file.
> 
> Now concurrent worker threads are not required to maintain a buffer queue, which would result in more memory overhead, nor do they need to compete for locks. The changes in the overall design are as follows:
> 
> ![image](https://github.com/openjdk/jdk/assets/5010047/86d2717d-c621-446f-98c2-cce761ec8db5)
> <p align="center">Fig1. Before</p>
> 
> ![image](https://github.com/openjdk/jdk/assets/5010047/c912c516-83b6-4343-a2e8-5d5bdb99cb87)
> <p align="center">Fig1. After this patch</p>
> 
> ### Performance evaluation
> | memory | numOfThread | STW         | Total      | Compression |
> | --- | --------- | -------------- | ------------ | -------- |
> | 8g | 1 thread | 15.612 secs | 15.612 secs | N |
> | 8g | 32 thread |  2.5617250 secs | 14.498 secs | N |
> | 8g | 32 thread | 2.3084878 secs | 3.198 secs | Compress1 |
> | 8g | 32 thread | 10.9355128 secs | 21.882 secs | Compress2 |
> | 8g | 96 thread | 2.6790452 secs | 14.012 secs | N |
> | 8g | 96 thread | 2.3044796 secs | 3.589 secs | Compress1 |
> | 8g | 96 thread | 9.7585151 secs | 20.219 secs| Compress2 |
> | 16g | 1 thread | 26.278 secs | 26.278 secs | N |
> | 16g | 32 thread |  5.2313740 secs | 26.417 secs | N |
> | 16g | 32 thread | 5.6946983 secs | 6.538 secs | Compress1 |
> | 16g | 32 thread | 21.8211105 secs | 41.133 secs | Compress2 |
> | 16g | 96 thread | 6.2445556 secs | 27.141 secs | N |
> | 16g | 96 thread | 4.6007096 secs | 6.259 secs | Compress1 |
> | 16g | 96 thread | 19.2965783 secs |  39.007 secs | Compress2 |
> | 32g | 1 thread | 48.149 secs | 48.149 secs | N |
> | 32g | 32 thread | 10.7734677 secs | 61.643 secs | N |
> | 32g | 32 thread | 10.1642097 secs | 10.903 secs | Compress1 |
> | 32g | 32 thread | 43.8407607 secs | 88.152 secs | Compress2 |
> | 32g | 96 thread | 13.1522042 secs | 61.432 secs | N |
> | 32g | 96 thread | 9.0954641 secs | 9.885 secs | C...

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  rename fetch_and_add to fetch_then_and

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13667/files
  - new: https://git.openjdk.org/jdk/pull/13667/files/02561629..ecab3116

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13667&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13667&range=11-12

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13667.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13667/head:pull/13667

PR: https://git.openjdk.org/jdk/pull/13667

From jaroslav.bachorik at datadoghq.com  Mon Jun 19 13:46:15 2023
From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=)
Date: Mon, 19 Jun 2023 15:46:15 +0200
Subject: Clarifying jmethodID Usage and Potential JVM Crashes
In-Reply-To: <154b6144-c209-af23-cc63-91b40f51076f@oracle.com>
References: <CAPb8aJ5K_1yk0FwTZOt_vzTXppB_=w5zK3guT6MDu6mpxeVRQA@mail.gmail.com>
 <31e606ae-f54e-c8e6-c00b-720ef192d279@oracle.com>
 <CAPb8aJ5kwQBLusLw0BWQQ9MGinmfu-HRfoo1cfBAEcP9AoC=7Q@mail.gmail.com>
 <e44d0811-76ca-aabe-c7df-08062e77d011@oracle.com>
 <154b6144-c209-af23-cc63-91b40f51076f@oracle.com>
Message-ID: <CAPb8aJ6u8sS_bsuY8egJafTjfzkJrcPLnPa=+WTDAkzozf9X+Q@mail.gmail.com>

Hi,

On Thu, Jun 1, 2023 at 5:49?PM <daniel.daugherty at oracle.com> wrote:

> Hmmm... seems like concurrent class unloading has revealed a situation
> in some
> code where class refs should have been held, but were not held because
> it's very
> difficult to do, and the code (mostly) got away with it for a long time...
>
> David's quote from the JNI spec makes things very, very clear:
>
>  > "A field or method ID does not prevent the VM from unloading the
> class from
>  > which the ID has been derived. After the class is unloaded, the method
> or
>  > field ID becomes invalid and may not be passed to any function taking
> such
>  > an ID. The native code, therefore, must make sure to:
>  >   - keep a live reference to the underlying class, or
>  >   - recompute the method or field ID
>  >
>  > if it intends to use a method or field ID for an extended period of
> time."
>
> and the JVM/TI spec does depend on the JNI spec for certain pieces like the
> semantics of jmethodID.
>
> I agree with David that fixing this is going to be difficult and a major
> effort which is why we've all only chipped at this boulder before...
>

I apologize for being a stickler, but it seems that the concurrent class
unloading and the ephemeral nature of jmethodIDs could cause problems even
for a much less exotic usecase of the JVMTI GetStackTrace (
https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#GetStackTrace
).
IIUC, the stacktrace consists of stack frames and each stack frame contains
a jmethodID identifying the associated Java method. Further on, obtaining
the stacktrace will not create references to corresponding classes so the
jmethodIDs can go 'bad' at any given moment, without an official way to
make sure such a 'bad' jmethodID would not crash JVM.

Cheers,

-JB-


>
> Dan
>
>
> On 6/1/23 4:28 AM, David Holmes wrote:
> > On 1/06/2023 5:16 pm, Jaroslav Bachor?k wrote:
> >> Hi David,
> >>
> >> On Thu, Jun 1, 2023 at 3:56?AM David Holmes <david.holmes at oracle.com
> >> <mailto:david.holmes at oracle.com>> wrote:
> >>
> >>     Hi Jaroslav,
> >>
> >>     On 31/05/2023 9:12 pm, Jaroslav Bachor?k wrote:
> >>      > Dear Team,
> >>      >
> >>      > I've been investigating the unusual JVM crashes occurring in
> >>     JVMTI calls
> >>      > on a J9 JVM. During my investigation, I scrutinized the
> >> `jmethodID`
> >>      > definition closely, available here: [jmethodID
> >>      >
> >> definition](
> https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#jmethodID
> >> <
> https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#jmethodID>
>
> >> <
> https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#jmethodID
> >> <
> https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#jmethodID>>).
>
> >>
> >>      >
> >>      > To paraphrase, the definition suggests that `jmethodID`
> >> identifies a
> >>      > Java method, initializer, or constructor. These identifiers, once
> >>      > returned by JVM TI functions and events, can be safely stored.
> >>     However,
> >>      > when the class is unloaded, they become invalid, rendering them
> >>      > unsuitable for use.
> >>      >
> >>      > My interpretation is that the JVMTI user should verify the
> >>     validity of a
> >>      > `jmethodID` value before using it to prevent potential crashes.
> >>     Would
> >>      > you agree with this interpretation?
> >>
> >>     Not quite - as you note you can't verify the jmethodID validity.
> >> What
> >>     the user needs to do, in line with what Dan was saying, is ensure
> >> that
> >>     they keep track of the classes to which the methods belong and keep
> >>     them
> >>     alive if necessary. Now that may be easier said than done, but
> >> that is
> >>     the gist of it. This comes from the JNI spec:
> >>
> >>     "A field or method ID does not prevent the VM from unloading the
> >> class
> >>     from which the ID has been derived. After the class is unloaded, the
> >>     method or field ID becomes invalid and may not be passed to any
> >>     function
> >>     taking such an ID. The native code, therefore, must make sure to:
> >>
> >>           keep a live reference to the underlying class, or
> >>           recompute the method or field ID
> >>
> >>     if it intends to use a method or field ID for an extended period of
> >>     time."
> >>
> >>      > This sounds like a sensible requirement, but its practical
> >>     application
> >>      > remains unclear. As far as I know, methods can be unloaded
> >>     concurrently
> >>      > to the native code executing JVMTI functions. This introduces a
> >>      > potential race condition where the JVM unloads the methods during
> >>     the
> >>      > check->use flow, making it only a partial solution. To complicate
> >>      > matters further, no method exists to confirm whether a
> >>     `jmethodID` is valid.
> >>      >
> >>      > Theoretically, we could monitor the `CompiledMethodUnload`
> >> event to
> >>      > track the validity state, creating a constantly expanding set of
> >>      > unloaded `jmethodID` values or a bloom filter, if one does not
> >> care
> >>      > about few potential false positives. This strategy, however,
> >> doesn't
> >>      > address the potential race condition, and it could even
> >>     exacerbate it
> >>      > due to possible event delays. This delay might mistakenly
> >> validate a
> >>      > `jmethodID` value that has already been unloaded, but for
> >> which the
> >>      > event hasn't been delivered yet.
> >>      >
> >>      > Honestly, I don't see a way to use `jmethodID` safely unless the
> >>     code
> >>      > using it suspends the entire JVM and doesn't resume until it's
> >>     finished
> >>      > with that `jmethodID`. Any other approach might lead to JVM
> >>     crashes, as
> >>      > we've observed with J9.
> >>      >
> >>      > Lastly, it's noteworthy that Hotspot takes meticulous measures to
> >>     ensure
> >>      > that using jmethodIDs for unloaded methods doesn't crash the
> >> JVM and
> >>      > even provides useful information. This observation has led me to
> >>      > question whether the documentation aligns with the Hotspot
> >>      > implementation, especially given that following closely the
> >>      > documentation appears to increase the risk associated with the
> >>     use of
> >>      > `jmethodID` values.
> >>
> >>     There have been folk who wanted to make this area more user-friendly
> >>     but
> >>     that shouldn't be mistaken for moving towards a world where
> >> jmethodIDs
> >>     are always safe to use.
> >>
> >>
> >> Yes, I see your point. Unfortunately, this confirms my worries that
> >> using AsyncGetCallTrace (ASGCT) on a system strictly adhering to the
> >> JVMTI spec of jmethoID is not really possible without risking random
> >> and quite frequent crashes on systems with concurrent class unloading
> >> enabled.
> >> FTR, ASGCT will record the stack trace as a list of frames, each one
> >> containing the corresponding jmethodID value. Considering that the
> >> most common usage of ASGCT is in a signal handler it makes it
> >> impossible to use JVMTI calls to resolve the holder class and create
> >> a strong reference to prevent it from being unloaded.
> >> And even if this would be possible we would need to figure out when
> >> to release the class reference when it is no more needed - and it is
> >> not really clear how we could do that reliably, leaving us with the
> >> option of holding the class references indefinitely or risking
> >> crashing JVM.
> >
> > I would have to agree you cannot use jmethodID's for that purpose, not
> > without also recording (and keeping-alive) the associated classes. As
> > to when you would clear such references I can't say as I don't know
> > how the ASGCT stack record would be used.
> >
> >> I want to emphasize that not being able to resolve additional details
> >> for a jmethodID pointing to a method of an unloaded class is not an
> >> issue, as long as the JVMTI call does not crash. I think that
> >> https://bugs.openjdk.org/browse/JDK-8268364
> >> <https://bugs.openjdk.org/browse/JDK-8268364> did address exactly the
> >> problem of concurrent class unloading causing races in the code that
> >> is checking for validity of jmethodID and then using it.
> >
> > Yes but internal to the JVMTI implementation. The basic null check
> > that was used was found to be insufficient when used with ZGC and so
> > we would crash more often than was considered reasonable. There is a
> > quoted comment in the code in
> > https://bugs.openjdk.org/browse/JDK-8268088:
> >
> >   // These aren't deallocated and are going to look like a leak, but
> > that's
> >   // needed because we can't really get rid of jmethodIDs because we
> > don't
> >   // know when native code is going to stop using them. The spec says
> > that
> >   // they're "invalid" but existing programs likely rely on their being
> >   // NULL after class unloading.
> >
> > that kind of sums up the position of trying to accommodate "bad code"
> > in a reasonable way.
> >
> >> Can this be summarize in a way that the user is not guaranteed to get
> >> any additional information for an invalid jmethodID but it would be
> >> really nice for JVM not to crash when jmethodID becomes invalid as
> >> there is no way for the user to check for its validity in an atomic
> >> manner
> >> - and yes, even calling GetMethodDeclaringClass in order to obtain
> >> the class one could create a strong reference is a subject to racy
> >> behaviour so it really can not be used as a workaround.
> >
> > The only real solution IMO would be to encode jmethodIDs in a way that
> > validity can be tracked and then have all JVMTI methods be able to
> > check that validity and guarantee atomicity of the method such that
> > the id can't become invalid whilst in use. Whether that is at all
> > feasible/practical I do not know - but it sounds like a major effort
> > to me.
> >
> > Cheers,
> > David
> >
> >> Cheers,
> >>
> >> -JB-
> >>
> >>
> >>     Cheers,
> >>     David
> >>
> >>      > I welcome your thoughts and perspectives on this matter.
> >>      >
> >>      > Best regards,
> >>      >
> >>      > Jaroslav
> >>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20230619/8e39f6e8/attachment-0001.htm>

From kevinw at openjdk.org  Mon Jun 19 19:08:18 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 19 Jun 2023 19:08:18 GMT
Subject: RFR: 8306446: java/lang/management/ThreadMXBean/Locks.java transient
 failures
Message-ID: <yJLcr84uu61lDSWtJkQy1FptnlzMKpsWs1HEuO9idPQ=.938810ca-26ec-4ed1-83f6-f59a01a25d47@github.com>

This test iterates an array of ThreadInfos in a few places (e.g. in the method doCheck()), and needs to tolerate and ignore nulls, in case a thread finishes and the test hits an NPE.

There are other calls like "TM.getThreadInfo(tid).getLockName()" which might often be risky, but if the threads are blocked as they are here, they can't be terminating, so this usage is safe.


The test has additional problems when started in a virtual thread.  ThreadMXBean.getThreadInfo() methods only return a ThreadInfo for platform threads.  The test needs to avoid some checks if mainThread is virtual.

In assertNoLock, it needs to not object to a thread holding a lock on a VirtualThread object is not relevant.
Also the loop in doChecks which follows a chain of locks... This needs to recognise that ForkJoinPool thead is not worth pursuing.  It's not one of the very narrow set of threads this test cares about.

Despite these exclusions, the test does some reasonable verification work when MainThread is virtual.  This test historically cam in with a general "JVM monitoring and management API" change, it is not testing a particular fix.


There's a failure condition in doCheck() which will not make the test fail: if it logs "TEST FAILED" in its final for loop, there is no failure.  Make the loop count the failures, and throw if there are any.

Also, while looking into this...  The variable names in some methods are confusing. In checkBlockedObject(), let's use "threadName" rather than "result" if we are finding a thread name, and let's not reuse the same result variable for a lockName later in the method.

The logs from this test are hard to read and verify, I find it better if the lock objects OBJB and OBJC are of classes other than Object, so you get to read, e.g.:
LockAThread blocked on Locks$ObjectB at 4691fdfd
(ObjectB, not just Object).

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

Commit messages:
 - condition change
 - 8306446: java/lang/management/ThreadMXBean/Locks.java transient failures

Changes: https://git.openjdk.org/jdk/pull/14501/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14501&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306446
  Stats: 51 lines in 1 file changed: 28 ins; 1 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/14501.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14501/head:pull/14501

PR: https://git.openjdk.org/jdk/pull/14501

From duke at openjdk.org  Mon Jun 19 20:06:06 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Mon, 19 Jun 2023 20:06:06 GMT
Subject: RFR: 8309979: BootstrapMethods attribute is missing in class files
 recreated by SA [v2]
In-Reply-To: <XMnH_cFQgCnx13I_1SqV-Br6T1QDwlbz9FzQZ-HlEaE=.f93bc591-726f-45fe-95ac-d1d6cfe79d06@github.com>
References: <nSooA6CtKm8LsaxzYdqJ6mtVV0os-kT5F2xNvYI4lJo=.c27bd28e-88d3-4bcb-ac3d-9036140eeff0@github.com>
 <i3PjGx_wbQ63SlwcWL5eBr28sDUb1_dPQ8Q0P3Qgzds=.5f11a8e5-714c-45c0-87e6-e612bb50b28b@github.com>
 <XMnH_cFQgCnx13I_1SqV-Br6T1QDwlbz9FzQZ-HlEaE=.f93bc591-726f-45fe-95ac-d1d6cfe79d06@github.com>
Message-ID: <U1Gysm5mq2IxQD3xmGvOLeNqqm_ZXRVe5ollPPGRDBw=.2e39150d-f3fd-4ba7-8ffe-30fb92f07fb6@github.com>

On Fri, 16 Jun 2023 18:10:58 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments by plummercj
>>   
>>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> Yes, it is already problem listed. How did you run the tests? If you use "make test" it should be including the problem list automatically.

@plummercj do you have any suggestions for who can be the second reviewer?

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

PR Comment: https://git.openjdk.org/jdk/pull/14495#issuecomment-1597697220

From dholmes at openjdk.org  Mon Jun 19 22:32:05 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 19 Jun 2023 22:32:05 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22 [v2]
In-Reply-To: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
Message-ID: <NuoEwbq5aPlw8_pQqyR8pHnCRBJJ9SxulvKOGyd9YJI=.a10acc7c-38dc-49d4-8e93-a46ff2cbcb0b@github.com>

> Updated the version to 22-ea and year to 2024.
> 
> The following unpublished changes will also be included in this update:
> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22:
> - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code
> - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor
> 
> Thanks.

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Pick up javac and jshell changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14462/files
  - new: https://git.openjdk.org/jdk/pull/14462/files/3efc518f..e8ff96d1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14462&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14462&range=00-01

  Stats: 74 lines in 2 files changed: 71 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14462.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14462/head:pull/14462

PR: https://git.openjdk.org/jdk/pull/14462

From dholmes at openjdk.org  Mon Jun 19 22:32:07 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 19 Jun 2023 22:32:07 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
Message-ID: <bunHkJGm3C7xSU0JqdU8O-z3rPLQw3xFScOef_2KnKo=.123f7217-2057-4ac6-b0fb-fd46c0c4c481@github.com>

On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Updated the version to 22-ea and year to 2024.
> 
> The following unpublished changes will also be included in this update:
> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22:
> - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code
> - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor
> 
> Thanks.

The javac changes have been restored so I am merging them into this PR - the only difference should be minor formatting changes.

This has also now picked up the jshell changes from JDK-8308988.

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

PR Comment: https://git.openjdk.org/jdk/pull/14462#issuecomment-1597836257

From dholmes at openjdk.org  Mon Jun 19 22:34:28 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 19 Jun 2023 22:34:28 GMT
Subject: RFR: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
Message-ID: <NBHlggX8F55iGpoySMQ3Ye20dSFyUnav1vexQ5yB8vI=.b5d8058d-4186-4584-877e-ca1b02688e48@github.com>

On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Updated the version to 22-ea and year to 2024.
> 
> The following unpublished changes will also be included in this update:
> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22:
> - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code
> - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor
> 
> Thanks.

The javac update has also now pulled in JDK-8308456

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

PR Comment: https://git.openjdk.org/jdk/pull/14462#issuecomment-1597839767

From dholmes at openjdk.org  Mon Jun 19 22:34:29 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 19 Jun 2023 22:34:29 GMT
Subject: Integrated: 8304478: Initial nroff manpage generation for JDK 22
In-Reply-To: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
References: <sfs3RJKVhvpg8gn_HCPGabFNxJUrcuT8K6Y3vj-egKo=.55190985-deeb-4424-9edb-34052a19b8ec@github.com>
Message-ID: <ZKcpvmC0cM2_o-sQJXe4-0F5A2z95lDQQ5VX5Qu4-HI=.d6b1c8bc-4110-4d09-ac97-098202d295e7@github.com>

On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Updated the version to 22-ea and year to 2024.
> 
> The following unpublished changes will also be included in this update:
> - [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626): keytool manpage contains a special character
> - [JDK-8303928](https://bugs.openjdk.org/browse/JDK-8303928): Update jarsigner man page after [JDK-8303410](https://bugs.openjdk.org/browse/JDK-8303410)
> - [JDK-8301207](https://bugs.openjdk.org/browse/JDK-8301207): (jdeps) Deprecate jdeps -profile option
> 
> The following changes, to `javac.1`, were never applied to the closed sources and are "lost" by this update. These changes will need to be re-applied directly in JDK 21 and JDK 22:
> - [JDK-8296656](https://bugs.openjdk.org/browse/JDK-8296656): java.lang.NoClassDefFoundError exception on running fully legitimate code
> - [JDK-8015831](https://bugs.openjdk.org/browse/JDK-8015831): Add lint check for calling overridable methods from a constructor
> 
> Thanks.

This pull request has now been integrated.

Changeset: b2e86aef
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b2e86aef65f4d579896b6db83aaad408b6c580d4
Stats:     129 lines in 28 files changed: 24 ins; 57 del; 48 mod

8304478: Initial nroff manpage generation for JDK 22

Reviewed-by: alanb, sspitsyn, mchung, lancea

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

PR: https://git.openjdk.org/jdk/pull/14462

From david.holmes at oracle.com  Tue Jun 20 02:38:29 2023
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 20 Jun 2023 12:38:29 +1000
Subject: Clarifying jmethodID Usage and Potential JVM Crashes
In-Reply-To: <CAPb8aJ6u8sS_bsuY8egJafTjfzkJrcPLnPa=+WTDAkzozf9X+Q@mail.gmail.com>
References: <CAPb8aJ5K_1yk0FwTZOt_vzTXppB_=w5zK3guT6MDu6mpxeVRQA@mail.gmail.com>
 <31e606ae-f54e-c8e6-c00b-720ef192d279@oracle.com>
 <CAPb8aJ5kwQBLusLw0BWQQ9MGinmfu-HRfoo1cfBAEcP9AoC=7Q@mail.gmail.com>
 <e44d0811-76ca-aabe-c7df-08062e77d011@oracle.com>
 <154b6144-c209-af23-cc63-91b40f51076f@oracle.com>
 <CAPb8aJ6u8sS_bsuY8egJafTjfzkJrcPLnPa=+WTDAkzozf9X+Q@mail.gmail.com>
Message-ID: <2514ebe0-f121-9c92-9058-914a430c461e@oracle.com>

On 19/06/2023 11:46 pm, Jaroslav Bachor?k wrote:
> Hi,
> 
> On Thu, Jun 1, 2023 at 5:49?PM <daniel.daugherty at oracle.com 
> <mailto:daniel.daugherty at oracle.com>> wrote:
> 
>     Hmmm... seems like concurrent class unloading has revealed a situation
>     in some
>     code where class refs should have been held, but were not held because
>     it's very
>     difficult to do, and the code (mostly) got away with it for a long
>     time...
> 
>     David's quote from the JNI spec makes things very, very clear:
> 
>      ?> "A field or method ID does not prevent the VM from unloading the
>     class from
>      ?> which the ID has been derived. After the class is unloaded, the
>     method or
>      ?> field ID becomes invalid and may not be passed to any function
>     taking
>     such
>      ?> an ID. The native code, therefore, must make sure to:
>      ?>?? - keep a live reference to the underlying class, or
>      ?>?? - recompute the method or field ID
>      ?>
>      ?> if it intends to use a method or field ID for an extended period of
>     time."
> 
>     and the JVM/TI spec does depend on the JNI spec for certain pieces
>     like the
>     semantics of jmethodID.
> 
>     I agree with David that fixing this is going to be difficult and a major
>     effort which is why we've all only chipped at this boulder before...
> 
> 
> I apologize for being a stickler, but it seems that the concurrent class 
> unloading and the ephemeral nature of jmethodIDs could cause problems 
> even for a much less exotic usecase of the JVMTI GetStackTrace 
> (https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#GetStackTrace <https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#GetStackTrace>).
> IIUC, the stacktrace consists of stack frames and each stack frame 
> contains a jmethodID identifying the associated Java method. Further on, 
> obtaining the stacktrace?will not create references to corresponding 
> classes so the jmethodIDs can go 'bad' at any given moment, without an 
> official way to make sure such a 'bad' jmethodID would not crash JVM.

Yep all correct. The jvmtiFrameInfo contains the jmethodID as applicable 
when the stacktrace was taken. If the current scope is not ensuring 
liveness then those method ids could be invalidated at any time.

I agree this is a hole in the JVM TI specification, but it is not a hole 
I know how to patch. Additional API are needed here along with changes 
to the validity requirements of jMethodIds.

Cheers,
David
-----

> Cheers,
> 
> -JB-
> 
> 
>     Dan
> 
> 
>     On 6/1/23 4:28 AM, David Holmes wrote:
>      > On 1/06/2023 5:16 pm, Jaroslav Bachor?k wrote:
>      >> Hi David,
>      >>
>      >> On Thu, Jun 1, 2023 at 3:56?AM David Holmes
>     <david.holmes at oracle.com <mailto:david.holmes at oracle.com>
>      >> <mailto:david.holmes at oracle.com
>     <mailto:david.holmes at oracle.com>>> wrote:
>      >>
>      >> ??? Hi Jaroslav,
>      >>
>      >> ??? On 31/05/2023 9:12 pm, Jaroslav Bachor?k wrote:
>      >> ???? > Dear Team,
>      >> ???? >
>      >> ???? > I've been investigating the unusual JVM crashes occurring in
>      >> ??? JVMTI calls
>      >> ???? > on a J9 JVM. During my investigation, I scrutinized the
>      >> `jmethodID`
>      >> ???? > definition closely, available here: [jmethodID
>      >> ???? >
>      >>
>     definition](https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#jmethodID <https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#jmethodID>
>      >>
>     <https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#jmethodID <https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#jmethodID>>
>      >>
>     <https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#jmethodID <https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#jmethodID>
>      >>
>     <https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#jmethodID <https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#jmethodID>>>).
>      >>
>      >> ???? >
>      >> ???? > To paraphrase, the definition suggests that `jmethodID`
>      >> identifies a
>      >> ???? > Java method, initializer, or constructor. These
>     identifiers, once
>      >> ???? > returned by JVM TI functions and events, can be safely
>     stored.
>      >> ??? However,
>      >> ???? > when the class is unloaded, they become invalid,
>     rendering them
>      >> ???? > unsuitable for use.
>      >> ???? >
>      >> ???? > My interpretation is that the JVMTI user should verify the
>      >> ??? validity of a
>      >> ???? > `jmethodID` value before using it to prevent potential
>     crashes.
>      >> ??? Would
>      >> ???? > you agree with this interpretation?
>      >>
>      >> ??? Not quite - as you note you can't verify the jmethodID
>     validity.
>      >> What
>      >> ??? the user needs to do, in line with what Dan was saying, is
>     ensure
>      >> that
>      >> ??? they keep track of the classes to which the methods belong
>     and keep
>      >> ??? them
>      >> ??? alive if necessary. Now that may be easier said than done, but
>      >> that is
>      >> ??? the gist of it. This comes from the JNI spec:
>      >>
>      >> ??? "A field or method ID does not prevent the VM from unloading
>     the
>      >> class
>      >> ??? from which the ID has been derived. After the class is
>     unloaded, the
>      >> ??? method or field ID becomes invalid and may not be passed to any
>      >> ??? function
>      >> ??? taking such an ID. The native code, therefore, must make
>     sure to:
>      >>
>      >> ???? ? ? ?keep a live reference to the underlying class, or
>      >> ???? ? ? ?recompute the method or field ID
>      >>
>      >> ??? if it intends to use a method or field ID for an extended
>     period of
>      >> ??? time."
>      >>
>      >> ???? > This sounds like a sensible requirement, but its practical
>      >> ??? application
>      >> ???? > remains unclear. As far as I know, methods can be unloaded
>      >> ??? concurrently
>      >> ???? > to the native code executing JVMTI functions. This
>     introduces a
>      >> ???? > potential race condition where the JVM unloads the
>     methods during
>      >> ??? the
>      >> ???? > check->use flow, making it only a partial solution. To
>     complicate
>      >> ???? > matters further, no method exists to confirm whether a
>      >> ??? `jmethodID` is valid.
>      >> ???? >
>      >> ???? > Theoretically, we could monitor the `CompiledMethodUnload`
>      >> event to
>      >> ???? > track the validity state, creating a constantly expanding
>     set of
>      >> ???? > unloaded `jmethodID` values or a bloom filter, if one
>     does not
>      >> care
>      >> ???? > about few potential false positives. This strategy, however,
>      >> doesn't
>      >> ???? > address the potential race condition, and it could even
>      >> ??? exacerbate it
>      >> ???? > due to possible event delays. This delay might mistakenly
>      >> validate a
>      >> ???? > `jmethodID` value that has already been unloaded, but for
>      >> which the
>      >> ???? > event hasn't been delivered yet.
>      >> ???? >
>      >> ???? > Honestly, I don't see a way to use `jmethodID` safely
>     unless the
>      >> ??? code
>      >> ???? > using it suspends the entire JVM and doesn't resume until
>     it's
>      >> ??? finished
>      >> ???? > with that `jmethodID`. Any other approach might lead to JVM
>      >> ??? crashes, as
>      >> ???? > we've observed with J9.
>      >> ???? >
>      >> ???? > Lastly, it's noteworthy that Hotspot takes meticulous
>     measures to
>      >> ??? ensure
>      >> ???? > that using jmethodIDs for unloaded methods doesn't crash the
>      >> JVM and
>      >> ???? > even provides useful information. This observation has
>     led me to
>      >> ???? > question whether the documentation aligns with the Hotspot
>      >> ???? > implementation, especially given that following closely the
>      >> ???? > documentation appears to increase the risk associated
>     with the
>      >> ??? use of
>      >> ???? > `jmethodID` values.
>      >>
>      >> ??? There have been folk who wanted to make this area more
>     user-friendly
>      >> ??? but
>      >> ??? that shouldn't be mistaken for moving towards a world where
>      >> jmethodIDs
>      >> ??? are always safe to use.
>      >>
>      >>
>      >> Yes, I see your point. Unfortunately, this confirms my worries that
>      >> using AsyncGetCallTrace (ASGCT) on a system strictly adhering to
>     the
>      >> JVMTI spec of jmethoID is not really possible without risking
>     random
>      >> and quite frequent crashes on systems with concurrent class
>     unloading
>      >> enabled.
>      >> FTR, ASGCT will record the stack trace as a list of frames, each
>     one
>      >> containing?the corresponding jmethodID value. Considering that the
>      >> most common usage of ASGCT is in a signal handler it makes it
>      >> impossible to use JVMTI calls to resolve the holder class and
>     create
>      >> a strong reference to prevent it from being unloaded.
>      >> And even if this would be possible we would need to figure out when
>      >> to release the class reference when it is no more needed - and
>     it is
>      >> not really clear how we could do that reliably, leaving us with the
>      >> option of holding the class references indefinitely or risking
>      >> crashing JVM.
>      >
>      > I would have to agree you cannot use jmethodID's for that
>     purpose, not
>      > without also recording (and keeping-alive) the associated
>     classes. As
>      > to when you would clear such references I can't say as I don't know
>      > how the ASGCT stack record would be used.
>      >
>      >> I want to emphasize that not being able to resolve additional
>     details
>      >> for a jmethodID pointing to a method of an unloaded class is not an
>      >> issue, as long as the JVMTI call does not crash. I think that
>      >> https://bugs.openjdk.org/browse/JDK-8268364
>     <https://bugs.openjdk.org/browse/JDK-8268364>
>      >> <https://bugs.openjdk.org/browse/JDK-8268364
>     <https://bugs.openjdk.org/browse/JDK-8268364>> did address exactly the
>      >> problem of concurrent class unloading causing races in the code
>     that
>      >> is checking for validity of jmethodID and then using it.
>      >
>      > Yes but internal to the JVMTI implementation. The basic null check
>      > that was used was found to be insufficient when used with ZGC and so
>      > we would crash more often than was considered reasonable. There is a
>      > quoted comment in the code in
>      > https://bugs.openjdk.org/browse/JDK-8268088
>     <https://bugs.openjdk.org/browse/JDK-8268088>:
>      >
>      > ? // These aren't deallocated and are going to look like a leak, but
>      > that's
>      > ? // needed because we can't really get rid of jmethodIDs because we
>      > don't
>      > ? // know when native code is going to stop using them. The spec
>     says
>      > that
>      > ? // they're "invalid" but existing programs likely rely on their
>     being
>      > ? // NULL after class unloading.
>      >
>      > that kind of sums up the position of trying to accommodate "bad
>     code"
>      > in a reasonable way.
>      >
>      >> Can this be summarize in a way that the user is not guaranteed
>     to get
>      >> any additional information for an invalid jmethodID but it would be
>      >> really nice for JVM not to crash when jmethodID becomes invalid as
>      >> there is no way for the user to check for its validity in an atomic
>      >> manner
>      >> - and yes, even calling GetMethodDeclaringClass in order to obtain
>      >> the class one could create a strong reference is a subject to racy
>      >> behaviour so it really can not be used as a workaround.
>      >
>      > The only real solution IMO would be to encode jmethodIDs in a way
>     that
>      > validity can be tracked and then have all JVMTI methods be able to
>      > check that validity and guarantee atomicity of the method such that
>      > the id can't become invalid whilst in use. Whether that is at all
>      > feasible/practical I do not know - but it sounds like a major effort
>      > to me.
>      >
>      > Cheers,
>      > David
>      >
>      >> Cheers,
>      >>
>      >> -JB-
>      >>
>      >>
>      >> ??? Cheers,
>      >> ??? David
>      >>
>      >> ???? > I welcome your thoughts and perspectives on this matter.
>      >> ???? >
>      >> ???? > Best regards,
>      >> ???? >
>      >> ???? > Jaroslav
>      >>
> 

From jaroslav.bachorik at datadoghq.com  Tue Jun 20 05:45:13 2023
From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=)
Date: Tue, 20 Jun 2023 07:45:13 +0200
Subject: Clarifying jmethodID Usage and Potential JVM Crashes
In-Reply-To: <2514ebe0-f121-9c92-9058-914a430c461e@oracle.com>
References: <CAPb8aJ5K_1yk0FwTZOt_vzTXppB_=w5zK3guT6MDu6mpxeVRQA@mail.gmail.com>
 <31e606ae-f54e-c8e6-c00b-720ef192d279@oracle.com>
 <CAPb8aJ5kwQBLusLw0BWQQ9MGinmfu-HRfoo1cfBAEcP9AoC=7Q@mail.gmail.com>
 <e44d0811-76ca-aabe-c7df-08062e77d011@oracle.com>
 <154b6144-c209-af23-cc63-91b40f51076f@oracle.com>
 <CAPb8aJ6u8sS_bsuY8egJafTjfzkJrcPLnPa=+WTDAkzozf9X+Q@mail.gmail.com>
 <2514ebe0-f121-9c92-9058-914a430c461e@oracle.com>
Message-ID: <CAPb8aJ6dtTufFbtkDHAo+RYy_xPf7-dfGEwoSzce4k8-OR-SSg@mail.gmail.com>

On Tue, Jun 20, 2023 at 4:38?AM David Holmes <david.holmes at oracle.com>
wrote:

> On 19/06/2023 11:46 pm, Jaroslav Bachor?k wrote:
> > Hi,
> >
> > On Thu, Jun 1, 2023 at 5:49?PM <daniel.daugherty at oracle.com
> > <mailto:daniel.daugherty at oracle.com>> wrote:
> >
> >     Hmmm... seems like concurrent class unloading has revealed a
> situation
> >     in some
> >     code where class refs should have been held, but were not held
> because
> >     it's very
> >     difficult to do, and the code (mostly) got away with it for a long
> >     time...
> >
> >     David's quote from the JNI spec makes things very, very clear:
> >
> >       > "A field or method ID does not prevent the VM from unloading the
> >     class from
> >       > which the ID has been derived. After the class is unloaded, the
> >     method or
> >       > field ID becomes invalid and may not be passed to any function
> >     taking
> >     such
> >       > an ID. The native code, therefore, must make sure to:
> >       >   - keep a live reference to the underlying class, or
> >       >   - recompute the method or field ID
> >       >
> >       > if it intends to use a method or field ID for an extended period
> of
> >     time."
> >
> >     and the JVM/TI spec does depend on the JNI spec for certain pieces
> >     like the
> >     semantics of jmethodID.
> >
> >     I agree with David that fixing this is going to be difficult and a
> major
> >     effort which is why we've all only chipped at this boulder before...
> >
> >
> > I apologize for being a stickler, but it seems that the concurrent class
> > unloading and the ephemeral nature of jmethodIDs could cause problems
> > even for a much less exotic usecase of the JVMTI GetStackTrace
> > (
> https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#GetStackTrace
> <
> https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#GetStackTrace
> >).
> > IIUC, the stacktrace consists of stack frames and each stack frame
> > contains a jmethodID identifying the associated Java method. Further on,
> > obtaining the stacktrace will not create references to corresponding
> > classes so the jmethodIDs can go 'bad' at any given moment, without an
> > official way to make sure such a 'bad' jmethodID would not crash JVM.
>
> Yep all correct. The jvmtiFrameInfo contains the jmethodID as applicable
> when the stacktrace was taken. If the current scope is not ensuring
> liveness then those method ids could be invalidated at any time.
>
> I agree this is a hole in the JVM TI specification, but it is not a hole
> I know how to patch. Additional API are needed here along with changes
> to the validity requirements of jMethodIds.
>

Thanks! Yes, this makes sense. I just wanted to make sure my perception was
correct.

Cheers,

-JB-


>
> Cheers,
> David
> -----
>
> > Cheers,
> >
> > -JB-
> >
> >
> >     Dan
> >
> >
> >     On 6/1/23 4:28 AM, David Holmes wrote:
> >      > On 1/06/2023 5:16 pm, Jaroslav Bachor?k wrote:
> >      >> Hi David,
> >      >>
> >      >> On Thu, Jun 1, 2023 at 3:56?AM David Holmes
> >     <david.holmes at oracle.com <mailto:david.holmes at oracle.com>
> >      >> <mailto:david.holmes at oracle.com
> >     <mailto:david.holmes at oracle.com>>> wrote:
> >      >>
> >      >>     Hi Jaroslav,
> >      >>
> >      >>     On 31/05/2023 9:12 pm, Jaroslav Bachor?k wrote:
> >      >>      > Dear Team,
> >      >>      >
> >      >>      > I've been investigating the unusual JVM crashes occurring
> in
> >      >>     JVMTI calls
> >      >>      > on a J9 JVM. During my investigation, I scrutinized the
> >      >> `jmethodID`
> >      >>      > definition closely, available here: [jmethodID
> >      >>      >
> >      >>
> >     definition](
> https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#jmethodID
> <https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#jmethodID
> >
> >      >>
> >     <
> https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#jmethodID
> <https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#jmethodID
> >>
> >      >>
> >     <
> https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#jmethodID
> <https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#jmethodID
> >
> >      >>
> >     <
> https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#jmethodID
> <https://docs.oracle.com/en/java/javase/17/docs/specs/jvmti.html#jmethodID
> >>>).
> >      >>
> >      >>      >
> >      >>      > To paraphrase, the definition suggests that `jmethodID`
> >      >> identifies a
> >      >>      > Java method, initializer, or constructor. These
> >     identifiers, once
> >      >>      > returned by JVM TI functions and events, can be safely
> >     stored.
> >      >>     However,
> >      >>      > when the class is unloaded, they become invalid,
> >     rendering them
> >      >>      > unsuitable for use.
> >      >>      >
> >      >>      > My interpretation is that the JVMTI user should verify the
> >      >>     validity of a
> >      >>      > `jmethodID` value before using it to prevent potential
> >     crashes.
> >      >>     Would
> >      >>      > you agree with this interpretation?
> >      >>
> >      >>     Not quite - as you note you can't verify the jmethodID
> >     validity.
> >      >> What
> >      >>     the user needs to do, in line with what Dan was saying, is
> >     ensure
> >      >> that
> >      >>     they keep track of the classes to which the methods belong
> >     and keep
> >      >>     them
> >      >>     alive if necessary. Now that may be easier said than done,
> but
> >      >> that is
> >      >>     the gist of it. This comes from the JNI spec:
> >      >>
> >      >>     "A field or method ID does not prevent the VM from unloading
> >     the
> >      >> class
> >      >>     from which the ID has been derived. After the class is
> >     unloaded, the
> >      >>     method or field ID becomes invalid and may not be passed to
> any
> >      >>     function
> >      >>     taking such an ID. The native code, therefore, must make
> >     sure to:
> >      >>
> >      >>           keep a live reference to the underlying class, or
> >      >>           recompute the method or field ID
> >      >>
> >      >>     if it intends to use a method or field ID for an extended
> >     period of
> >      >>     time."
> >      >>
> >      >>      > This sounds like a sensible requirement, but its practical
> >      >>     application
> >      >>      > remains unclear. As far as I know, methods can be unloaded
> >      >>     concurrently
> >      >>      > to the native code executing JVMTI functions. This
> >     introduces a
> >      >>      > potential race condition where the JVM unloads the
> >     methods during
> >      >>     the
> >      >>      > check->use flow, making it only a partial solution. To
> >     complicate
> >      >>      > matters further, no method exists to confirm whether a
> >      >>     `jmethodID` is valid.
> >      >>      >
> >      >>      > Theoretically, we could monitor the `CompiledMethodUnload`
> >      >> event to
> >      >>      > track the validity state, creating a constantly expanding
> >     set of
> >      >>      > unloaded `jmethodID` values or a bloom filter, if one
> >     does not
> >      >> care
> >      >>      > about few potential false positives. This strategy,
> however,
> >      >> doesn't
> >      >>      > address the potential race condition, and it could even
> >      >>     exacerbate it
> >      >>      > due to possible event delays. This delay might mistakenly
> >      >> validate a
> >      >>      > `jmethodID` value that has already been unloaded, but for
> >      >> which the
> >      >>      > event hasn't been delivered yet.
> >      >>      >
> >      >>      > Honestly, I don't see a way to use `jmethodID` safely
> >     unless the
> >      >>     code
> >      >>      > using it suspends the entire JVM and doesn't resume until
> >     it's
> >      >>     finished
> >      >>      > with that `jmethodID`. Any other approach might lead to
> JVM
> >      >>     crashes, as
> >      >>      > we've observed with J9.
> >      >>      >
> >      >>      > Lastly, it's noteworthy that Hotspot takes meticulous
> >     measures to
> >      >>     ensure
> >      >>      > that using jmethodIDs for unloaded methods doesn't crash
> the
> >      >> JVM and
> >      >>      > even provides useful information. This observation has
> >     led me to
> >      >>      > question whether the documentation aligns with the Hotspot
> >      >>      > implementation, especially given that following closely
> the
> >      >>      > documentation appears to increase the risk associated
> >     with the
> >      >>     use of
> >      >>      > `jmethodID` values.
> >      >>
> >      >>     There have been folk who wanted to make this area more
> >     user-friendly
> >      >>     but
> >      >>     that shouldn't be mistaken for moving towards a world where
> >      >> jmethodIDs
> >      >>     are always safe to use.
> >      >>
> >      >>
> >      >> Yes, I see your point. Unfortunately, this confirms my worries
> that
> >      >> using AsyncGetCallTrace (ASGCT) on a system strictly adhering to
> >     the
> >      >> JVMTI spec of jmethoID is not really possible without risking
> >     random
> >      >> and quite frequent crashes on systems with concurrent class
> >     unloading
> >      >> enabled.
> >      >> FTR, ASGCT will record the stack trace as a list of frames, each
> >     one
> >      >> containing the corresponding jmethodID value. Considering that
> the
> >      >> most common usage of ASGCT is in a signal handler it makes it
> >      >> impossible to use JVMTI calls to resolve the holder class and
> >     create
> >      >> a strong reference to prevent it from being unloaded.
> >      >> And even if this would be possible we would need to figure out
> when
> >      >> to release the class reference when it is no more needed - and
> >     it is
> >      >> not really clear how we could do that reliably, leaving us with
> the
> >      >> option of holding the class references indefinitely or risking
> >      >> crashing JVM.
> >      >
> >      > I would have to agree you cannot use jmethodID's for that
> >     purpose, not
> >      > without also recording (and keeping-alive) the associated
> >     classes. As
> >      > to when you would clear such references I can't say as I don't
> know
> >      > how the ASGCT stack record would be used.
> >      >
> >      >> I want to emphasize that not being able to resolve additional
> >     details
> >      >> for a jmethodID pointing to a method of an unloaded class is not
> an
> >      >> issue, as long as the JVMTI call does not crash. I think that
> >      >> https://bugs.openjdk.org/browse/JDK-8268364
> >     <https://bugs.openjdk.org/browse/JDK-8268364>
> >      >> <https://bugs.openjdk.org/browse/JDK-8268364
> >     <https://bugs.openjdk.org/browse/JDK-8268364>> did address exactly
> the
> >      >> problem of concurrent class unloading causing races in the code
> >     that
> >      >> is checking for validity of jmethodID and then using it.
> >      >
> >      > Yes but internal to the JVMTI implementation. The basic null check
> >      > that was used was found to be insufficient when used with ZGC and
> so
> >      > we would crash more often than was considered reasonable. There
> is a
> >      > quoted comment in the code in
> >      > https://bugs.openjdk.org/browse/JDK-8268088
> >     <https://bugs.openjdk.org/browse/JDK-8268088>:
> >      >
> >      >   // These aren't deallocated and are going to look like a leak,
> but
> >      > that's
> >      >   // needed because we can't really get rid of jmethodIDs because
> we
> >      > don't
> >      >   // know when native code is going to stop using them. The spec
> >     says
> >      > that
> >      >   // they're "invalid" but existing programs likely rely on their
> >     being
> >      >   // NULL after class unloading.
> >      >
> >      > that kind of sums up the position of trying to accommodate "bad
> >     code"
> >      > in a reasonable way.
> >      >
> >      >> Can this be summarize in a way that the user is not guaranteed
> >     to get
> >      >> any additional information for an invalid jmethodID but it would
> be
> >      >> really nice for JVM not to crash when jmethodID becomes invalid
> as
> >      >> there is no way for the user to check for its validity in an
> atomic
> >      >> manner
> >      >> - and yes, even calling GetMethodDeclaringClass in order to
> obtain
> >      >> the class one could create a strong reference is a subject to
> racy
> >      >> behaviour so it really can not be used as a workaround.
> >      >
> >      > The only real solution IMO would be to encode jmethodIDs in a way
> >     that
> >      > validity can be tracked and then have all JVMTI methods be able to
> >      > check that validity and guarantee atomicity of the method such
> that
> >      > the id can't become invalid whilst in use. Whether that is at all
> >      > feasible/practical I do not know - but it sounds like a major
> effort
> >      > to me.
> >      >
> >      > Cheers,
> >      > David
> >      >
> >      >> Cheers,
> >      >>
> >      >> -JB-
> >      >>
> >      >>
> >      >>     Cheers,
> >      >>     David
> >      >>
> >      >>      > I welcome your thoughts and perspectives on this matter.
> >      >>      >
> >      >>      > Best regards,
> >      >>      >
> >      >>      > Jaroslav
> >      >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20230620/02943b7c/attachment-0001.htm>

From dnsimon at openjdk.org  Tue Jun 20 06:50:11 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 20 Jun 2023 06:50:11 GMT
Subject: RFR: 8309671: Avoid using jvmci.Compiler property to determine if
 Graal is enabled
In-Reply-To: <29D590lYaxvw5XS9uU-De3N2NJ3thhNWoWU7eQkhpfc=.80aa7b3c-7ab2-41a9-940f-8db0caefaaee@github.com>
References: <IawBz7ECRbEFc1GCsQzaP0-LR7HwlplLrLkuZOnn-fk=.ac148e99-c5c4-4571-abaa-6025458e63ce@github.com>
 <vmLY_SLrhMau31-t5ijS-y2q0DcNy-sy7CaF5HuoBq0=.af5cdf71-1126-4958-a918-86f5afd0a6bc@github.com>
 <29D590lYaxvw5XS9uU-De3N2NJ3thhNWoWU7eQkhpfc=.80aa7b3c-7ab2-41a9-940f-8db0caefaaee@github.com>
Message-ID: <-YtApF9RHktQLsRRX9cQylAfpIunVNpe8IAppRuGlps=.120415c2-d7d6-458e-85b9-0c10d53d8e23@github.com>

On Fri, 9 Jun 2023 12:14:46 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> > Is JVMCI used by the Graal compiler only?
> 
> So far this is true and will probably remain true for the foreseeable future. However, the Right Thing to do long term is to add a `jdk.test.whitebox.code.Compiler.uncommonTrapsHavePreciseBCIs()` method.

I created https://bugs.openjdk.org/browse/JDK-8310346 for this enhancement.

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

PR Comment: https://git.openjdk.org/jdk/pull/14381#issuecomment-1598205886

From jwaters at openjdk.org  Tue Jun 20 07:20:12 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 20 Jun 2023 07:20:12 GMT
Subject: RFR: 8305341: Alignment should be enforced by alignas instead of
 compiler specific attributes [v5]
In-Reply-To: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
Message-ID: <OO54CVLdk0uWvMSIzS8ePDvGv2rbYJNQlqk7QZTyRiM=.4dabc87c-f302-4b61-8d02-9678ad243a5b@github.com>

> C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements

Julian Waters has updated the pull request incrementally with three additional commits since the last revision:

 - Whitespace
 - Revert
 - _MSC_VER

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13258/files
  - new: https://git.openjdk.org/jdk/pull/13258/files/e63d5938..2fed50f4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13258&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13258&range=03-04

  Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13258.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13258/head:pull/13258

PR: https://git.openjdk.org/jdk/pull/13258

From jwaters at openjdk.org  Tue Jun 20 07:20:13 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 20 Jun 2023 07:20:13 GMT
Subject: RFR: 8305341: Alignment should be enforced by alignas instead of
 compiler specific attributes [v4]
In-Reply-To: <dlMKfkRoYlEOlABs5J-mW-Mbr-M3Kv455fgrnmj0A1w=.954ab66c-6dfb-44e7-9546-455e38e35f4a@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
 <dlMKfkRoYlEOlABs5J-mW-Mbr-M3Kv455fgrnmj0A1w=.954ab66c-6dfb-44e7-9546-455e38e35f4a@github.com>
Message-ID: <r3nzdMOZ2jyvmb8397B91p7Df8rcFsUeCRsZrun17Yc=.c5d9be48-55bc-4044-8cfe-204591638642@github.com>

On Wed, 12 Apr 2023 07:12:10 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements
>
> Julian Waters has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Restore visCPP
>  - Restore gcc attribute
>  - Revert gcc
>  - Revert

Bumping

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

PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1598236477

From aboldtch at openjdk.org  Tue Jun 20 10:11:15 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 20 Jun 2023 10:11:15 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v3]
In-Reply-To: <Y0_ibTPlMn3qi6kp4Yiq5UgiiAabHFZMYtg9MxkUI4Q=.1609fbef-0242-4cd8-b93f-e2feeeb7ff96@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
 <3yy4WQIDq7tTBt53suFujkDg7UK2cR8gllrNnWHBLgY=.280e5138-a3c0-4bbe-874f-572a1c30638e@github.com>
 <Y0_ibTPlMn3qi6kp4Yiq5UgiiAabHFZMYtg9MxkUI4Q=.1609fbef-0242-4cd8-b93f-e2feeeb7ff96@github.com>
Message-ID: <VDW3BGJ096WIM-W4o8iASPVBxgFZUODEGU7-jMzvcxk=.e6ab6339-bf00-487c-afdd-2ef09b9d5b08@github.com>

On Mon, 19 Jun 2023 09:04:17 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> How much time do we spend now in GHAs on the additional Zgenerational tests? In any case, this makes sense.

This adds around 40 more tests per platform. The runtime of GHA seems to have a lot of run to run variance. Most new tests are in the `hs/tier1 gc` which has a lower runtime than a few other jobs. So until the heavies jobs gets split into multiple jobs,   this should have a negligible affect the overall GHA runtime

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

PR Comment: https://git.openjdk.org/jdk/pull/14509#issuecomment-1598488556

From aboldtch at openjdk.org  Tue Jun 20 10:11:18 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 20 Jun 2023 10:11:18 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v3]
In-Reply-To: <3yy4WQIDq7tTBt53suFujkDg7UK2cR8gllrNnWHBLgY=.280e5138-a3c0-4bbe-874f-572a1c30638e@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
 <3yy4WQIDq7tTBt53suFujkDg7UK2cR8gllrNnWHBLgY=.280e5138-a3c0-4bbe-874f-572a1c30638e@github.com>
Message-ID: <_wzHFl48ZJqPvYFTwOtY4ughHH3EvHSH9-JtsJiAiXg=.c0e787e7-7797-4a50-a6d3-1b4ef9dfd39e@github.com>

On Mon, 19 Jun 2023 06:55:52 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The current implementation for testing generational ZGC with jtreg is implemented with a filter on the mode flag `ZGenerational`. Because of this only environments which set this flag explicitly will run most of the tests. 
>> So they get missed in Github Actions and for developers running jtreg locally without supplying the `ZGenerational` flag.
>> 
>> The proposed change here is to introduce two new jtreg requirement properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will effectively behave the same as the existing `vm.gc.<GC>` flags but also take the specific ZGC mode in account.
>> 
>> If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will be true.
>> 
>> If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will also be true.
>> 
>> If `-XX:{+,-}ZGenerational` is supplied then either  `vm.gc.ZGenerational` or `vm.gc.ZSinglegen` be true depending on the flags value.
>> 
>> And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will be false.
>> 
>> This change also splits the relevant tests into two distinct runs for the two modes. And the respective test ids are set to `ZGenerational` or `ZSinglegen` to make it easier to distinguish the runs.
>> 
>> This also solves the issue that some compiler tests will never run with generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the current filter `vm.opt.final.ZGenerational` requires the flag to be explicit, but these compiler tests uses `vm.flagless`. 
>> 
>> The introduction of  `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` harmonizes the way you specify generational / single gen ZGC test with the way it is done for other gcs with `vm.gc.<GC>`
>> 
>> To support this feature the Whitebox API is extended with `isDefaultVMFlag` to enable checking if `ZGenerational` is default or not.
>> 
>> `vm.opt.final.ZGenerational` is still kept because we still have some reasons to filter based on the supplied flags. 
>> - `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when running with ZGenerational
>> - `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with a different max heap size for ZGenerational, but it is not the intent to dispatch the test to both G1 and generational ZGC if Generational ZGC is not specified.  
>> 
>> `test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed to not filter but instead dispatch. However u...
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add explicit id to all Skynet.java @test

Thanks for all the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/14509#issuecomment-1598489642

From aboldtch at openjdk.org  Tue Jun 20 10:11:19 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 20 Jun 2023 10:11:19 GMT
Subject: Integrated: 8310187: Improve Generational ZGC jtreg testing
In-Reply-To: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
Message-ID: <XBb9N9mM3eUuzE3Hn7dEBfENSBizoTw539Co_-H_ngs=.898b8ddf-b6dd-42e0-9e6c-986800b61005@github.com>

On Fri, 16 Jun 2023 09:14:10 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The current implementation for testing generational ZGC with jtreg is implemented with a filter on the mode flag `ZGenerational`. Because of this only environments which set this flag explicitly will run most of the tests. 
> So they get missed in Github Actions and for developers running jtreg locally without supplying the `ZGenerational` flag.
> 
> The proposed change here is to introduce two new jtreg requirement properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will effectively behave the same as the existing `vm.gc.<GC>` flags but also take the specific ZGC mode in account.
> 
> If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will be true.
> 
> If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will also be true.
> 
> If `-XX:{+,-}ZGenerational` is supplied then either  `vm.gc.ZGenerational` or `vm.gc.ZSinglegen` be true depending on the flags value.
> 
> And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will be false.
> 
> This change also splits the relevant tests into two distinct runs for the two modes. And the respective test ids are set to `ZGenerational` or `ZSinglegen` to make it easier to distinguish the runs.
> 
> This also solves the issue that some compiler tests will never run with generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the current filter `vm.opt.final.ZGenerational` requires the flag to be explicit, but these compiler tests uses `vm.flagless`. 
> 
> The introduction of  `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` harmonizes the way you specify generational / single gen ZGC test with the way it is done for other gcs with `vm.gc.<GC>`
> 
> To support this feature the Whitebox API is extended with `isDefaultVMFlag` to enable checking if `ZGenerational` is default or not.
> 
> `vm.opt.final.ZGenerational` is still kept because we still have some reasons to filter based on the supplied flags. 
> - `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when running with ZGenerational
> - `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with a different max heap size for ZGenerational, but it is not the intent to dispatch the test to both G1 and generational ZGC if Generational ZGC is not specified.  
> 
> `test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed to not filter but instead dispatch. However unsure if this change should be included. The change ...

This pull request has now been integrated.

Changeset: a0595761
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a0595761ef35c4eec8cb84326a869b9473cd5bba
Stats:     619 lines in 70 files changed: 447 ins; 5 del; 167 mod

8310187: Improve Generational ZGC jtreg testing

Reviewed-by: stefank, eosterlund, stuefe

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

PR: https://git.openjdk.org/jdk/pull/14509

From aboldtch at openjdk.org  Tue Jun 20 11:24:22 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 20 Jun 2023 11:24:22 GMT
Subject: [jdk21] RFR: 8310187: Improve Generational ZGC jtreg testing
Message-ID: <cxzJD8H_hBo9D066bXYhT9TKHj2-83IRtHw6hbD0h3s=.09fc98f5-5fd1-42f5-b1c2-9b198c0956fc@github.com>

Hi all,

This pull request contains a backport of commit [a0595761](https://github.com/openjdk/jdk/commit/a0595761ef35c4eec8cb84326a869b9473cd5bba) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Axel Boldt-Christmas on 20 Jun 2023 and was reviewed by Stefan Karlsson, Erik ?sterlund and Thomas Stuefe.

Thanks!

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

Commit messages:
 - Backport a0595761ef35c4eec8cb84326a869b9473cd5bba

Changes: https://git.openjdk.org/jdk21/pull/37/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=37&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310187
  Stats: 619 lines in 70 files changed: 447 ins; 5 del; 167 mod
  Patch: https://git.openjdk.org/jdk21/pull/37.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/37/head:pull/37

PR: https://git.openjdk.org/jdk21/pull/37

From eosterlund at openjdk.org  Tue Jun 20 11:28:10 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 20 Jun 2023 11:28:10 GMT
Subject: [jdk21] RFR: 8310187: Improve Generational ZGC jtreg testing
In-Reply-To: <cxzJD8H_hBo9D066bXYhT9TKHj2-83IRtHw6hbD0h3s=.09fc98f5-5fd1-42f5-b1c2-9b198c0956fc@github.com>
References: <cxzJD8H_hBo9D066bXYhT9TKHj2-83IRtHw6hbD0h3s=.09fc98f5-5fd1-42f5-b1c2-9b198c0956fc@github.com>
Message-ID: <4_7pKKc53x4JitLz3mqqGPROusebWNzImc2QiYeNOLw=.bfba6681-1a22-4e5b-8669-d6261cc129e3@github.com>

On Tue, 20 Jun 2023 11:17:40 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [a0595761](https://github.com/openjdk/jdk/commit/a0595761ef35c4eec8cb84326a869b9473cd5bba) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Axel Boldt-Christmas on 20 Jun 2023 and was reviewed by Stefan Karlsson, Erik ?sterlund and Thomas Stuefe.
> 
> Thanks!

Looks good.

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

Marked as reviewed by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/37#pullrequestreview-1487924209

From duke at openjdk.org  Tue Jun 20 11:40:17 2023
From: duke at openjdk.org (Daohan Qu)
Date: Tue, 20 Jun 2023 11:40:17 GMT
Subject: RFR: 8242152: SA does not include StackMapTables when dumping .class
 files
Message-ID: <pBErA6eLKjV5Ydj7YKeOTkHW4VvuaylzXSdt2-QG2PE=.d4b64495-fbfd-467b-ad70-448e71fb3b1b@github.com>

This patch adds `StackMapTable` for the class files generated by `clhsdb`'s `buildreplayjars` command. This bug manifests itself during my diagnosing [JDK-8309751](https://bugs.openjdk.org/browse/JDK-8309751) and needs to be fixed first.

I have run jtreg test `tier1-3` of release build on x86 linux finding only one failure in `tier2` caused by [JDK-8309214](https://bugs.openjdk.org/browse/JDK-8309214). And `jtreg:test/hotspot/jtreg/serviceability` also passed.

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

Commit messages:
 - Add StackMapTable for the class file generated by jhsdb

Changes: https://git.openjdk.org/jdk/pull/14556/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14556&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8242152
  Stats: 57 lines in 3 files changed: 57 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14556.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14556/head:pull/14556

PR: https://git.openjdk.org/jdk/pull/14556

From mbaesken at openjdk.org  Tue Jun 20 13:30:59 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 20 Jun 2023 13:30:59 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS when
 codesign tool does not work
Message-ID: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>

Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
But without the entitlement, a core is not generated.

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

Commit messages:
 - JDK-8310380

Changes: https://git.openjdk.org/jdk/pull/14562/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14562&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310380
  Stats: 36 lines in 3 files changed: 35 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14562.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14562/head:pull/14562

PR: https://git.openjdk.org/jdk/pull/14562

From stefank at openjdk.org  Tue Jun 20 13:47:05 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 20 Jun 2023 13:47:05 GMT
Subject: RFR: 8310194: Generational ZGC: Lock-order asserts in JVMTI
 IterateThroughHeap
In-Reply-To: <JFgqaXsFv8JyuOzQuXC3sioAeiGTZxTiw-4gnX-j6Ok=.6a2ceeb4-b304-46cb-be4e-9816beeb7d6a@github.com>
References: <JFgqaXsFv8JyuOzQuXC3sioAeiGTZxTiw-4gnX-j6Ok=.6a2ceeb4-b304-46cb-be4e-9816beeb7d6a@github.com>
Message-ID: <mY-Xje3zO4_r27pB508TxxV5g78fvaXnSOvxOr5-85o=.b0ca6eae-1809-4df1-bcaa-f50b3526f13c@github.com>

On Fri, 16 Jun 2023 11:52:51 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Generational ZGC changed the location where the heap object iterator called the visit function. It used to be called when the objects were popped and then followed, but it was changed so that the function where called immediately when the objects are marked. This gave the benefit that the verification code code show exactly what root had a broken object. Unfortunately, this change started to apply non-GC closure during the root iteration. This could lead to lock order issues, just like the one described in the JBS entry.
> 
> This fix moves the visit calls for non-GC closures back to the follow calls.

Thanks for reviewing!

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

PR Comment: https://git.openjdk.org/jdk/pull/14518#issuecomment-1598821180

From stefank at openjdk.org  Tue Jun 20 13:50:12 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 20 Jun 2023 13:50:12 GMT
Subject: Integrated: 8310194: Generational ZGC: Lock-order asserts in JVMTI
 IterateThroughHeap
In-Reply-To: <JFgqaXsFv8JyuOzQuXC3sioAeiGTZxTiw-4gnX-j6Ok=.6a2ceeb4-b304-46cb-be4e-9816beeb7d6a@github.com>
References: <JFgqaXsFv8JyuOzQuXC3sioAeiGTZxTiw-4gnX-j6Ok=.6a2ceeb4-b304-46cb-be4e-9816beeb7d6a@github.com>
Message-ID: <YUpS6Ty9EH1ORz6lAZJqlb9vUUEA7vZUZ6aoCpEEqKo=.b97e41f3-108c-4514-9900-f6a112717743@github.com>

On Fri, 16 Jun 2023 11:52:51 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Generational ZGC changed the location where the heap object iterator called the visit function. It used to be called when the objects were popped and then followed, but it was changed so that the function where called immediately when the objects are marked. This gave the benefit that the verification code code show exactly what root had a broken object. Unfortunately, this change started to apply non-GC closure during the root iteration. This could lead to lock order issues, just like the one described in the JBS entry.
> 
> This fix moves the visit calls for non-GC closures back to the follow calls.

This pull request has now been integrated.

Changeset: 4e4e586d
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4e4e586dac3f4be15a6488a6b72aa9e2cd5d43db
Stats:     203 lines in 5 files changed: 103 ins; 37 del; 63 mod

8310194: Generational ZGC: Lock-order asserts in JVMTI IterateThroughHeap

Reviewed-by: eosterlund, aboldtch

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

PR: https://git.openjdk.org/jdk/pull/14518

From duke at openjdk.org  Tue Jun 20 14:05:04 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Tue, 20 Jun 2023 14:05:04 GMT
Subject: RFR: 8242152: SA does not include StackMapTables when dumping
 .class files
In-Reply-To: <pBErA6eLKjV5Ydj7YKeOTkHW4VvuaylzXSdt2-QG2PE=.d4b64495-fbfd-467b-ad70-448e71fb3b1b@github.com>
References: <pBErA6eLKjV5Ydj7YKeOTkHW4VvuaylzXSdt2-QG2PE=.d4b64495-fbfd-467b-ad70-448e71fb3b1b@github.com>
Message-ID: <-bsxwXfcNV2hPRiMWFxooI_JyA4ElhRpoLJlhJj_tbc=.8fe4003e-582e-455d-a667-4d440d2434a4@github.com>

On Tue, 20 Jun 2023 11:31:40 GMT, Daohan Qu <duke at openjdk.org> wrote:

> This patch adds `StackMapTable` for the class files generated by `clhsdb`'s `buildreplayjars` command. This bug manifests itself during my diagnosing [JDK-8309751](https://bugs.openjdk.org/browse/JDK-8309751) and needs to be fixed first.
> 
> I have run jtreg test `tier1-3` of release build on x86 linux finding only one failure in `tier2` caused by [JDK-8309214](https://bugs.openjdk.org/browse/JDK-8309214). `jtreg:test/hotspot/jtreg/serviceability` and `jtreg:test/jdk/sun/tools/` also passed.

@quadhier you beat me to this! Changes look good.

On another note since you mentioned [JDK-8309751](https://bugs.openjdk.org/browse/JDK-8309751) I should let you know I have a fix for it  and am planning to open a PR soon. My bad that I didn't assign that issue to myself before starting working on it.

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

PR Comment: https://git.openjdk.org/jdk/pull/14556#issuecomment-1598858991

From duke at openjdk.org  Tue Jun 20 14:12:02 2023
From: duke at openjdk.org (Daohan Qu)
Date: Tue, 20 Jun 2023 14:12:02 GMT
Subject: RFR: 8242152: SA does not include StackMapTables when dumping
 .class files
In-Reply-To: <-bsxwXfcNV2hPRiMWFxooI_JyA4ElhRpoLJlhJj_tbc=.8fe4003e-582e-455d-a667-4d440d2434a4@github.com>
References: <pBErA6eLKjV5Ydj7YKeOTkHW4VvuaylzXSdt2-QG2PE=.d4b64495-fbfd-467b-ad70-448e71fb3b1b@github.com>
 <-bsxwXfcNV2hPRiMWFxooI_JyA4ElhRpoLJlhJj_tbc=.8fe4003e-582e-455d-a667-4d440d2434a4@github.com>
Message-ID: <HgUdw7d6uy0HVIGCpjaV-yB77jIO7rIBINeMD3asg7o=.1f0750e2-883e-4485-98bf-1db0cd52bd5b@github.com>

On Tue, 20 Jun 2023 14:02:35 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

> On another note since you mentioned [JDK-8309751](https://bugs.openjdk.org/browse/JDK-8309751) I should let you know I have a fix for it and am planning to open a PR soon.

Good news! Never mind and thanks for your notice ?.

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

PR Comment: https://git.openjdk.org/jdk/pull/14556#issuecomment-1598870945

From never at openjdk.org  Tue Jun 20 18:11:25 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Tue, 20 Jun 2023 18:11:25 GMT
Subject: RFR: 8294316: SA core file support is broken on macosx-x64 starting
 with macOS 12.x
Message-ID: <0wPtkRqjB3Nh6LiABARFcqq6UqcCsTNbF1ok1iG0Efw=.af55940f-5b2d-4cfb-b233-066a419bae48@github.com>

This is a minor fix to core file reading on macos x.  I can confirm that after this fix I can run the problem listed SA core file tests on Ventura.

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

Commit messages:
 - 8294316: SA core file support is broken on macosx-x64 starting with macOS 12.x

Changes: https://git.openjdk.org/jdk/pull/14569/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14569&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294316
  Stats: 20 lines in 2 files changed: 7 ins; 3 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/14569.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14569/head:pull/14569

PR: https://git.openjdk.org/jdk/pull/14569

From cjplummer at openjdk.org  Tue Jun 20 18:31:06 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 20 Jun 2023 18:31:06 GMT
Subject: [jdk21] RFR: 8308499: Test
 vmTestbase/nsk/jdi/MethodExitRequest/addClassExclusionFilter/filter001/TestDescription.java
 failed: VMDisconnectedException
Message-ID: <v4xIOmW5F8629A8LjZvdfLnOB-ZBodA8BcvJ0eVxr4E=.509f3cac-7309-405b-80af-eb6228b56bd4@github.com>

Clean backport of [JDK-8308499](https://bugs.openjdk.org/browse/JDK-8308499)

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

Commit messages:
 - Backport 79ff72a7762deb6010b57e5ac0ccede3d035ab4c

Changes: https://git.openjdk.org/jdk21/pull/41/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=41&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308499
  Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk21/pull/41.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/41/head:pull/41

PR: https://git.openjdk.org/jdk21/pull/41

From kevinw at openjdk.org  Tue Jun 20 20:13:09 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 20 Jun 2023 20:13:09 GMT
Subject: [jdk21] RFR: 8308499: Test
 vmTestbase/nsk/jdi/MethodExitRequest/addClassExclusionFilter/filter001/TestDescription.java
 failed: VMDisconnectedException
In-Reply-To: <v4xIOmW5F8629A8LjZvdfLnOB-ZBodA8BcvJ0eVxr4E=.509f3cac-7309-405b-80af-eb6228b56bd4@github.com>
References: <v4xIOmW5F8629A8LjZvdfLnOB-ZBodA8BcvJ0eVxr4E=.509f3cac-7309-405b-80af-eb6228b56bd4@github.com>
Message-ID: <eT7cZab2R_4gCsttQgkgAepU9i3m46o6QP4GiPqQy9w=.340f8440-be73-40e5-a370-6126fd6d9a75@github.com>

On Tue, 20 Jun 2023 18:25:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Clean backport of [JDK-8308499](https://bugs.openjdk.org/browse/JDK-8308499)

Looks good.

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

Marked as reviewed by kevinw (Committer).

PR Review: https://git.openjdk.org/jdk21/pull/41#pullrequestreview-1488944096

From prr at openjdk.org  Tue Jun 20 20:25:15 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 20 Jun 2023 20:25:15 GMT
Subject: RFR: 8310187: Improve Generational ZGC jtreg testing [v3]
In-Reply-To: <3yy4WQIDq7tTBt53suFujkDg7UK2cR8gllrNnWHBLgY=.280e5138-a3c0-4bbe-874f-572a1c30638e@github.com>
References: <jNf2r1-DZZVVZclTPCkbpmPJ7E_m2d34BHy4rA8lm-M=.f14b1be8-53e1-43fd-a6cb-728e13595e47@github.com>
 <3yy4WQIDq7tTBt53suFujkDg7UK2cR8gllrNnWHBLgY=.280e5138-a3c0-4bbe-874f-572a1c30638e@github.com>
Message-ID: <ELnPTmj_oP5vV_spnx855G7rHvSrglS31H2TwRQ1xwg=.8557871f-3ab2-40ed-bee4-2574c1865be9@github.com>

On Mon, 19 Jun 2023 06:55:52 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The current implementation for testing generational ZGC with jtreg is implemented with a filter on the mode flag `ZGenerational`. Because of this only environments which set this flag explicitly will run most of the tests. 
>> So they get missed in Github Actions and for developers running jtreg locally without supplying the `ZGenerational` flag.
>> 
>> The proposed change here is to introduce two new jtreg requirement properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will effectively behave the same as the existing `vm.gc.<GC>` flags but also take the specific ZGC mode in account.
>> 
>> If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will be true.
>> 
>> If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will also be true.
>> 
>> If `-XX:{+,-}ZGenerational` is supplied then either  `vm.gc.ZGenerational` or `vm.gc.ZSinglegen` be true depending on the flags value.
>> 
>> And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` will be false.
>> 
>> This change also splits the relevant tests into two distinct runs for the two modes. And the respective test ids are set to `ZGenerational` or `ZSinglegen` to make it easier to distinguish the runs.
>> 
>> This also solves the issue that some compiler tests will never run with generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the current filter `vm.opt.final.ZGenerational` requires the flag to be explicit, but these compiler tests uses `vm.flagless`. 
>> 
>> The introduction of  `vm.gc.ZGenerational` and `vm.gc.ZSinglegen` harmonizes the way you specify generational / single gen ZGC test with the way it is done for other gcs with `vm.gc.<GC>`
>> 
>> To support this feature the Whitebox API is extended with `isDefaultVMFlag` to enable checking if `ZGenerational` is default or not.
>> 
>> `vm.opt.final.ZGenerational` is still kept because we still have some reasons to filter based on the supplied flags. 
>> - `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when running with ZGenerational
>> - `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with a different max heap size for ZGenerational, but it is not the intent to dispatch the test to both G1 and generational ZGC if Generational ZGC is not specified.  
>> 
>> `test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed to not filter but instead dispatch. However u...
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add explicit id to all Skynet.java @test

I have no issues with the enhanced Java 2D tests to cover both generational and original ZGC.
But I'll leave it to hotspot reviews to formally approve the fix since those tests are such a tiny part of this.

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

PR Comment: https://git.openjdk.org/jdk/pull/14509#issuecomment-1599445397

From sspitsyn at openjdk.org  Wed Jun 21 01:18:09 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 21 Jun 2023 01:18:09 GMT
Subject: [jdk21] RFR: 8303916: ThreadLists.java inconsistent results
In-Reply-To: <EM-gSGWADuTyVdSaS_8MNv8pMUUGz6JRFidTnHww304=.8747b919-93e6-46ef-aac9-0da01c80033b@github.com>
References: <EM-gSGWADuTyVdSaS_8MNv8pMUUGz6JRFidTnHww304=.8747b919-93e6-46ef-aac9-0da01c80033b@github.com>
Message-ID: <TeDjdy8UOdUHhL93BTgrOfUFAzD8ViSmZ6bCOaKaR-c=.7262d723-958e-4596-a9a0-600f3b185a71@github.com>

On Fri, 16 Jun 2023 09:15:52 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Clean backport from latest jdk repo to jdk21 for the test change:
> 8303916: ThreadLists.java inconsistent results

The backport looks clean.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/24#pullrequestreview-1489465539

From sspitsyn at openjdk.org  Wed Jun 21 02:14:24 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 21 Jun 2023 02:14:24 GMT
Subject: [jdk21] RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on
 carrier should return STATE_WAITING
Message-ID: <PzhO6iHSzQRBnKp_ElR_slY7sqVMzsgwfsHI3IMaiOQ=.d57a3477-cb32-4ae8-a6a4-cdb09749517e@github.com>

Clean backport from latest jdk repo to jdk21 for the fix of:
  8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING

Testing:
 - TBD: mach5 tiers 1-5

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

Commit messages:
 - Backport f91e9ba757f04983655c23542e06973805465249

Changes: https://git.openjdk.org/jdk21/pull/43/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=43&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309612
  Stats: 96 lines in 4 files changed: 76 ins; 0 del; 20 mod
  Patch: https://git.openjdk.org/jdk21/pull/43.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/43/head:pull/43

PR: https://git.openjdk.org/jdk21/pull/43

From mbaesken at openjdk.org  Wed Jun 21 07:35:51 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 21 Jun 2023 07:35:51 GMT
Subject: [jdk21] RFR: 8309549:
 com/sun/tools/attach/warnings/DynamicLoadWarningTest.java fails on AIX
Message-ID: <R8izXvq03A2DBBoOs3qKl8Th5NLpR79YubvRZnunn9Y=.53331a6d-246a-4f1f-8aa8-7aa05e7a03be@github.com>

8309549: com/sun/tools/attach/warnings/DynamicLoadWarningTest.java fails on AIX

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

Commit messages:
 - Backport 4d66d977450e083214da3dba6ad4ed851c6c1cb4

Changes: https://git.openjdk.org/jdk21/pull/44/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=44&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309549
  Stats: 7 lines in 1 file changed: 3 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk21/pull/44.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/44/head:pull/44

PR: https://git.openjdk.org/jdk21/pull/44

From lucy at openjdk.org  Wed Jun 21 07:44:09 2023
From: lucy at openjdk.org (Lutz Schmidt)
Date: Wed, 21 Jun 2023 07:44:09 GMT
Subject: [jdk21] RFR: 8309549:
 com/sun/tools/attach/warnings/DynamicLoadWarningTest.java fails on AIX
In-Reply-To: <R8izXvq03A2DBBoOs3qKl8Th5NLpR79YubvRZnunn9Y=.53331a6d-246a-4f1f-8aa8-7aa05e7a03be@github.com>
References: <R8izXvq03A2DBBoOs3qKl8Th5NLpR79YubvRZnunn9Y=.53331a6d-246a-4f1f-8aa8-7aa05e7a03be@github.com>
Message-ID: <EJmrn1YiAHbyddZIg05PnnQMLhGc_RCcYugJ9CN1lus=.4db71dae-66e5-4a69-b8d1-ad9c050f545c@github.com>

On Wed, 21 Jun 2023 07:29:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> 8309549: com/sun/tools/attach/warnings/DynamicLoadWarningTest.java fails on AIX

LGTM.
Thanks for fixing.

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

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/44#pullrequestreview-1489979713

From alanb at openjdk.org  Wed Jun 21 07:44:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 Jun 2023 07:44:10 GMT
Subject: [jdk21] RFR: 8309549:
 com/sun/tools/attach/warnings/DynamicLoadWarningTest.java fails on AIX
In-Reply-To: <R8izXvq03A2DBBoOs3qKl8Th5NLpR79YubvRZnunn9Y=.53331a6d-246a-4f1f-8aa8-7aa05e7a03be@github.com>
References: <R8izXvq03A2DBBoOs3qKl8Th5NLpR79YubvRZnunn9Y=.53331a6d-246a-4f1f-8aa8-7aa05e7a03be@github.com>
Message-ID: <c2Ky0TaCTEWHb__OipRYeDynssoBuJer4JqqCEs0QQE=.a10022a7-9d0f-47cf-a723-d5b7f60936b1@github.com>

On Wed, 21 Jun 2023 07:29:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> 8309549: com/sun/tools/attach/warnings/DynamicLoadWarningTest.java fails on AIX

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/44#pullrequestreview-1489982868

From djelinski at openjdk.org  Wed Jun 21 07:48:10 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 21 Jun 2023 07:48:10 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v5]
In-Reply-To: <uTI-0-FTTOiVf6_6psxvUks06Xj57078fd8yzoUkb5E=.d0f3deb0-8199-46fc-b259-18d41ad3cbbb@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <uTI-0-FTTOiVf6_6psxvUks06Xj57078fd8yzoUkb5E=.d0f3deb0-8199-46fc-b259-18d41ad3cbbb@github.com>
Message-ID: <e03s86poTfLMgZxAIbbZrWI80VKIVgor9KM-f9egCU0=.2f374c5d-b95b-4262-a452-7b3dd96643bc@github.com>

On Sun, 11 Jun 2023 16:38:31 GMT, Artem Semenov <asemenov at openjdk.org> 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 with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - update
>  - update
>  - update
>  - update
>  - 8308286 Fix clang warnings in linux code

Please update copyright years where they aren't at 2023 yet.

I verified these changes on Ubuntu 20.04 + clang 10; they are both necessary and sufficient to make the build pass with warnings as errors. I saw one more warning:

clang: warning: argument unused during compilation: '-static-libstdc++' [-Wunused-command-line-argument]

in `BUILD_SYSLOOKUPLIB_link.log`, but that one does not break the build.

I'm going to approve this once you fix the mentioned issues. Thanks for working on this!

make/modules/java.desktop/lib/Awt2dLibraries.gmk line 235:

> 233:         DISABLED_WARNINGS_gcc := int-to-pointer-cast, \
> 234:         DISABLED_WARNINGS_gcc_awt_Taskbar.c := parentheses, \
> 235:         DISABLED_WARNINGS_clang_awt_Taskbar.c := parentheses, \

please group the disabled warnings by compiler (gcc, then clang, then clang_aix)

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

PR Review: https://git.openjdk.org/jdk/pull/14033#pullrequestreview-1489972241
PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1236510850

From mbaesken at openjdk.org  Wed Jun 21 07:51:05 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 21 Jun 2023 07:51:05 GMT
Subject: [jdk21] RFR: 8309549:
 com/sun/tools/attach/warnings/DynamicLoadWarningTest.java fails on AIX
In-Reply-To: <R8izXvq03A2DBBoOs3qKl8Th5NLpR79YubvRZnunn9Y=.53331a6d-246a-4f1f-8aa8-7aa05e7a03be@github.com>
References: <R8izXvq03A2DBBoOs3qKl8Th5NLpR79YubvRZnunn9Y=.53331a6d-246a-4f1f-8aa8-7aa05e7a03be@github.com>
Message-ID: <X2YsZkM5EMxWjPbIWT26e2WrwcMWlQ9J92q852-LqX0=.82eea40d-4360-466d-9475-faa64d71ec0f@github.com>

On Wed, 21 Jun 2023 07:29:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> 8309549: com/sun/tools/attach/warnings/DynamicLoadWarningTest.java fails on AIX

Alan and Lucy , thanks !

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

PR Comment: https://git.openjdk.org/jdk21/pull/44#issuecomment-1600349549

From mbaesken at openjdk.org  Wed Jun 21 07:51:07 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 21 Jun 2023 07:51:07 GMT
Subject: [jdk21] Integrated: 8309549:
 com/sun/tools/attach/warnings/DynamicLoadWarningTest.java fails on AIX
In-Reply-To: <R8izXvq03A2DBBoOs3qKl8Th5NLpR79YubvRZnunn9Y=.53331a6d-246a-4f1f-8aa8-7aa05e7a03be@github.com>
References: <R8izXvq03A2DBBoOs3qKl8Th5NLpR79YubvRZnunn9Y=.53331a6d-246a-4f1f-8aa8-7aa05e7a03be@github.com>
Message-ID: <4DiKSBcIY6GgSw7dAQmJe2gBzafyEMpA-OOVnJesGjs=.75e18ab4-069a-44a2-affb-7fd91e80bfec@github.com>

On Wed, 21 Jun 2023 07:29:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> 8309549: com/sun/tools/attach/warnings/DynamicLoadWarningTest.java fails on AIX

This pull request has now been integrated.

Changeset: 60cae33c
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/60cae33c46d74de462e4b5abfc3b7379d98f1311
Stats:     7 lines in 1 file changed: 3 ins; 0 del; 4 mod

8309549: com/sun/tools/attach/warnings/DynamicLoadWarningTest.java fails on AIX

Reviewed-by: lucy, alanb
Backport-of: 4d66d977450e083214da3dba6ad4ed851c6c1cb4

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

PR: https://git.openjdk.org/jdk21/pull/44

From mbaesken at openjdk.org  Wed Jun 21 08:34:22 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 21 Jun 2023 08:34:22 GMT
Subject: [jdk21] RFR: 8310191:
 com/sun/tools/attach/warnings/DynamicLoadWarningTest.java second failure on
 AIX
Message-ID: <wRrs7LMauKh8RLJTE9OEKaKlQ9j44g2u9Dub66tqsqs=.3c98bd9d-1a9b-480a-a279-a733acfd49e0@github.com>

8310191: com/sun/tools/attach/warnings/DynamicLoadWarningTest.java second failure on AIX

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

Commit messages:
 - Backport 6a63badd8ea3e79cd9fc3cb33aff499fc9a6d3f1

Changes: https://git.openjdk.org/jdk21/pull/45/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=45&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310191
  Stats: 20 lines in 1 file changed: 8 ins; 8 del; 4 mod
  Patch: https://git.openjdk.org/jdk21/pull/45.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/45/head:pull/45

PR: https://git.openjdk.org/jdk21/pull/45

From alanb at openjdk.org  Wed Jun 21 08:48:03 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 Jun 2023 08:48:03 GMT
Subject: [jdk21] RFR: 8310191:
 com/sun/tools/attach/warnings/DynamicLoadWarningTest.java second failure on
 AIX
In-Reply-To: <wRrs7LMauKh8RLJTE9OEKaKlQ9j44g2u9Dub66tqsqs=.3c98bd9d-1a9b-480a-a279-a733acfd49e0@github.com>
References: <wRrs7LMauKh8RLJTE9OEKaKlQ9j44g2u9Dub66tqsqs=.3c98bd9d-1a9b-480a-a279-a733acfd49e0@github.com>
Message-ID: <fx3VF5N9S9yAOSyayGJDRGfzKNgFNVsW6itU-DJhgv0=.2ac5c383-a2b5-4271-9da2-088f5a081bc8@github.com>

On Wed, 21 Jun 2023 08:27:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> 8310191: com/sun/tools/attach/warnings/DynamicLoadWarningTest.java second failure on AIX

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/45#pullrequestreview-1490174297

From mbaesken at openjdk.org  Wed Jun 21 09:05:07 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 21 Jun 2023 09:05:07 GMT
Subject: [jdk21] Integrated: 8310191:
 com/sun/tools/attach/warnings/DynamicLoadWarningTest.java second failure on
 AIX
In-Reply-To: <wRrs7LMauKh8RLJTE9OEKaKlQ9j44g2u9Dub66tqsqs=.3c98bd9d-1a9b-480a-a279-a733acfd49e0@github.com>
References: <wRrs7LMauKh8RLJTE9OEKaKlQ9j44g2u9Dub66tqsqs=.3c98bd9d-1a9b-480a-a279-a733acfd49e0@github.com>
Message-ID: <ywGwoT3MinZ1Ph-67QNhNmwWbweO6sp5yxLxaGMhDG0=.41b0f1bf-bebc-4d53-9a27-9ae5c2db7e79@github.com>

On Wed, 21 Jun 2023 08:27:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> 8310191: com/sun/tools/attach/warnings/DynamicLoadWarningTest.java second failure on AIX

This pull request has now been integrated.

Changeset: 1fc60429
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/1fc60429a1565ca5357de08c53df53af5d24278f
Stats:     20 lines in 1 file changed: 8 ins; 8 del; 4 mod

8310191: com/sun/tools/attach/warnings/DynamicLoadWarningTest.java second failure on AIX

Reviewed-by: alanb
Backport-of: 6a63badd8ea3e79cd9fc3cb33aff499fc9a6d3f1

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

PR: https://git.openjdk.org/jdk21/pull/45

From kcr at openjdk.org  Wed Jun 21 12:30:06 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 21 Jun 2023 12:30:06 GMT
Subject: [jdk21] RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on
 carrier should return STATE_WAITING
In-Reply-To: <PzhO6iHSzQRBnKp_ElR_slY7sqVMzsgwfsHI3IMaiOQ=.d57a3477-cb32-4ae8-a6a4-cdb09749517e@github.com>
References: <PzhO6iHSzQRBnKp_ElR_slY7sqVMzsgwfsHI3IMaiOQ=.d57a3477-cb32-4ae8-a6a4-cdb09749517e@github.com>
Message-ID: <QOMampEd3kAV22OAv2gku94_3U9hpc6UgkkBs5VNhrE=.ed7bbe3d-a8f8-4fee-8d42-fbd7896e21f9@github.com>

On Wed, 21 Jun 2023 02:07:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Clean backport from latest jdk repo to jdk21 for the fix of:
>   8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING
> 
> Testing:
>  - TBD: mach5 tiers 1-5

NOTE: if you change the PR title to `Backport COMMITHASH` as suggested by Skara in the __Issue__ section of the PR description, Skara will be able to verify whether the backport is clean, and also mark it as a Backport.

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

PR Comment: https://git.openjdk.org/jdk21/pull/43#issuecomment-1600743628

From aturbanov at openjdk.org  Wed Jun 21 12:37:08 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 21 Jun 2023 12:37:08 GMT
Subject: RFR: 8306446: java/lang/management/ThreadMXBean/Locks.java
 transient failures
In-Reply-To: <yJLcr84uu61lDSWtJkQy1FptnlzMKpsWs1HEuO9idPQ=.938810ca-26ec-4ed1-83f6-f59a01a25d47@github.com>
References: <yJLcr84uu61lDSWtJkQy1FptnlzMKpsWs1HEuO9idPQ=.938810ca-26ec-4ed1-83f6-f59a01a25d47@github.com>
Message-ID: <eKqqUTcodBti-_j8Z0IeiBZgR22KxgRW3Tgqo6eUG4U=.13656319-41e8-4c15-b382-6841db6ed341@github.com>

On Thu, 15 Jun 2023 20:34:53 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test iterates an array of ThreadInfos in a few places (e.g. in the method doCheck()), and needs to tolerate and ignore nulls, in case a thread finishes and the test hits an NPE.
> 
> There are other calls like "TM.getThreadInfo(tid).getLockName()" which might often be risky, but if the threads are blocked as they are here, they can't be terminating, so this usage is safe.
> 
> 
> The test has additional problems when started in a virtual thread.  ThreadMXBean.getThreadInfo() methods only return a ThreadInfo for platform threads.  The test needs to avoid some checks if mainThread is virtual.
> 
> In assertNoLock, it needs to not object to a thread holding a lock on a VirtualThread object is not relevant.
> Also the loop in doChecks which follows a chain of locks... This needs to recognise that ForkJoinPool thead is not worth pursuing.  It's not one of the very narrow set of threads this test cares about.
> 
> Despite these exclusions, the test does some reasonable verification work when MainThread is virtual.  This test historically cam in with a general "JVM monitoring and management API" change, it is not testing a particular fix.
> 
> 
> There's a failure condition in doCheck() which will not make the test fail: if it logs "TEST FAILED" in its final for loop, there is no failure.  Make the loop count the failures, and throw if there are any.
> 
> Also, while looking into this...  The variable names in some methods are confusing. In checkBlockedObject(), let's use "threadName" rather than "result" if we are finding a thread name, and let's not reuse the same result variable for a lockName later in the method.
> 
> The logs from this test are hard to read and verify, I find it better if the lock objects OBJB and OBJC are of classes other than Object, so you get to read, e.g.:
> LockAThread blocked on Locks$ObjectB at 4691fdfd
> (ObjectB, not just Object).

test/jdk/java/lang/management/ThreadMXBean/Locks.java line 72:

> 70:                                             .filter(Objects::nonNull)
> 71:                                             .filter(i -> name.equals(i.getLockOwnerName()))
> 72:                                             .filter(i  -> !i.getLockName().contains("java.lang.VirtualThread"))

Suggestion:

                                            .filter(i -> !i.getLockName().contains("java.lang.VirtualThread"))

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14501#discussion_r1236928027

From alanb at openjdk.org  Wed Jun 21 12:41:07 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 Jun 2023 12:41:07 GMT
Subject: RFR: 8306446: java/lang/management/ThreadMXBean/Locks.java
 transient failures
In-Reply-To: <eKqqUTcodBti-_j8Z0IeiBZgR22KxgRW3Tgqo6eUG4U=.13656319-41e8-4c15-b382-6841db6ed341@github.com>
References: <yJLcr84uu61lDSWtJkQy1FptnlzMKpsWs1HEuO9idPQ=.938810ca-26ec-4ed1-83f6-f59a01a25d47@github.com>
 <eKqqUTcodBti-_j8Z0IeiBZgR22KxgRW3Tgqo6eUG4U=.13656319-41e8-4c15-b382-6841db6ed341@github.com>
Message-ID: <V_cUYaGMH73KRkS8-egv6p9KDAKKkg16qBwK3hUdXJc=.735b1b8f-342f-451f-ac09-cfcc45d8dbfc@github.com>

On Wed, 21 Jun 2023 12:33:46 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> This test iterates an array of ThreadInfos in a few places (e.g. in the method doCheck()), and needs to tolerate and ignore nulls, in case a thread finishes and the test hits an NPE.
>> 
>> There are other calls like "TM.getThreadInfo(tid).getLockName()" which might often be risky, but if the threads are blocked as they are here, they can't be terminating, so this usage is safe.
>> 
>> 
>> The test has additional problems when started in a virtual thread.  ThreadMXBean.getThreadInfo() methods only return a ThreadInfo for platform threads.  The test needs to avoid some checks if mainThread is virtual.
>> 
>> In assertNoLock, it needs to not object to a thread holding a lock on a VirtualThread object is not relevant.
>> Also the loop in doChecks which follows a chain of locks... This needs to recognise that ForkJoinPool thead is not worth pursuing.  It's not one of the very narrow set of threads this test cares about.
>> 
>> Despite these exclusions, the test does some reasonable verification work when MainThread is virtual.  This test historically cam in with a general "JVM monitoring and management API" change, it is not testing a particular fix.
>> 
>> 
>> There's a failure condition in doCheck() which will not make the test fail: if it logs "TEST FAILED" in its final for loop, there is no failure.  Make the loop count the failures, and throw if there are any.
>> 
>> Also, while looking into this...  The variable names in some methods are confusing. In checkBlockedObject(), let's use "threadName" rather than "result" if we are finding a thread name, and let's not reuse the same result variable for a lockName later in the method.
>> 
>> The logs from this test are hard to read and verify, I find it better if the lock objects OBJB and OBJC are of classes other than Object, so you get to read, e.g.:
>> LockAThread blocked on Locks$ObjectB at 4691fdfd
>> (ObjectB, not just Object).
>
> test/jdk/java/lang/management/ThreadMXBean/Locks.java line 72:
> 
>> 70:                                             .filter(Objects::nonNull)
>> 71:                                             .filter(i -> name.equals(i.getLockOwnerName()))
>> 72:                                             .filter(i  -> !i.getLockName().contains("java.lang.VirtualThread"))
> 
> Suggestion:
> 
>                                             .filter(i -> !i.getLockName().contains("java.lang.VirtualThread"))

ThreadMXBean::getAllThreadsIds returns an array of the thread IDs of platform threads, it doesn't include virtual threads, so I don't know why this filter is added.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14501#discussion_r1236933317

From kevinw at openjdk.org  Wed Jun 21 12:50:08 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 21 Jun 2023 12:50:08 GMT
Subject: RFR: 8309979: BootstrapMethods attribute is missing in class files
 recreated by SA [v2]
In-Reply-To: <i3PjGx_wbQ63SlwcWL5eBr28sDUb1_dPQ8Q0P3Qgzds=.5f11a8e5-714c-45c0-87e6-e612bb50b28b@github.com>
References: <nSooA6CtKm8LsaxzYdqJ6mtVV0os-kT5F2xNvYI4lJo=.c27bd28e-88d3-4bcb-ac3d-9036140eeff0@github.com>
 <i3PjGx_wbQ63SlwcWL5eBr28sDUb1_dPQ8Q0P3Qgzds=.5f11a8e5-714c-45c0-87e6-e612bb50b28b@github.com>
Message-ID: <wPJDcnIRp7n6ysns1roSDQMM_Z448k6g74sT6g7-QuM=.2456dc2d-55ef-49e6-98ed-26efb1019ca6@github.com>

On Thu, 15 Jun 2023 20:24:39 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> Please review this PR that extends SA to write BootstrapMethods attribute when dumping the class files.
>> 
>> Tested it by dumping the class file for java/lang/String and comparing the BootstrapMethods attribute shown by javap for the original and the dumped class.
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments by plummercj
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java line 756:

> 754:                 }
> 755:             }
> 756:         }

Hi, it looks odd to me that we only write one short in the loop: should that be a bootstrap method ref, num arguments, and arguments?

I was comparing with: https://docs.oracle.com/javase/specs/jvms/se20/jvms20.pdf
4.7.23 The BootstrapMethods Attribute

We have bootstrap attribute written by other code, e.g.
"src/jdk.jdeps/share/classes/com/sun/tools/classfile/ClassWriter.java" 
visitBootstrapMethods

"src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java" 
writeBootstrapMethods

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14495#discussion_r1236945616

From kevinw at openjdk.org  Wed Jun 21 12:59:34 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 21 Jun 2023 12:59:34 GMT
Subject: RFR: 8306446: java/lang/management/ThreadMXBean/Locks.java
 transient failures [v2]
In-Reply-To: <V_cUYaGMH73KRkS8-egv6p9KDAKKkg16qBwK3hUdXJc=.735b1b8f-342f-451f-ac09-cfcc45d8dbfc@github.com>
References: <yJLcr84uu61lDSWtJkQy1FptnlzMKpsWs1HEuO9idPQ=.938810ca-26ec-4ed1-83f6-f59a01a25d47@github.com>
 <eKqqUTcodBti-_j8Z0IeiBZgR22KxgRW3Tgqo6eUG4U=.13656319-41e8-4c15-b382-6841db6ed341@github.com>
 <V_cUYaGMH73KRkS8-egv6p9KDAKKkg16qBwK3hUdXJc=.735b1b8f-342f-451f-ac09-cfcc45d8dbfc@github.com>
Message-ID: <7k4nEEHLK8O2r5IKZwfAMWOpyDO6FCLNvFX71MZPeVY=.6f93e611-3844-480e-b189-c97a3ef1900c@github.com>

On Wed, 21 Jun 2023 12:38:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> test/jdk/java/lang/management/ThreadMXBean/Locks.java line 72:
>> 
>>> 70:                                             .filter(Objects::nonNull)
>>> 71:                                             .filter(i -> name.equals(i.getLockOwnerName()))
>>> 72:                                             .filter(i  -> !i.getLockName().contains("java.lang.VirtualThread"))
>> 
>> Suggestion:
>> 
>>                                             .filter(i -> !i.getLockName().contains("java.lang.VirtualThread"))
>
> ThreadMXBean::getAllThreadsIds returns an array of the thread IDs of platform threads, it doesn't include virtual threads, so I don't know why this filter is added.

Whitespace correction, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14501#discussion_r1236955281

From kevinw at openjdk.org  Wed Jun 21 12:59:34 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 21 Jun 2023 12:59:34 GMT
Subject: RFR: 8306446: java/lang/management/ThreadMXBean/Locks.java
 transient failures [v2]
In-Reply-To: <yJLcr84uu61lDSWtJkQy1FptnlzMKpsWs1HEuO9idPQ=.938810ca-26ec-4ed1-83f6-f59a01a25d47@github.com>
References: <yJLcr84uu61lDSWtJkQy1FptnlzMKpsWs1HEuO9idPQ=.938810ca-26ec-4ed1-83f6-f59a01a25d47@github.com>
Message-ID: <iTJ5AEu-T787czfA7ixbBjStokmwXTDx2wKvQIR4oxg=.7faddbd9-b031-461c-9093-5fa70fd6ea55@github.com>

> This test iterates an array of ThreadInfos in a few places (e.g. in the method doCheck()), and needs to tolerate and ignore nulls, in case a thread finishes and the test hits an NPE.
> 
> There are other calls like "TM.getThreadInfo(tid).getLockName()" which might often be risky, but if the threads are blocked as they are here, they can't be terminating, so this usage is safe.
> 
> 
> The test has additional problems when started in a virtual thread.  ThreadMXBean.getThreadInfo() methods only return a ThreadInfo for platform threads.  The test needs to avoid some checks if mainThread is virtual.
> 
> In assertNoLock, it needs to not object to a thread holding a lock on a VirtualThread object is not relevant.
> Also the loop in doChecks which follows a chain of locks... This needs to recognise that ForkJoinPool thead is not worth pursuing.  It's not one of the very narrow set of threads this test cares about.
> 
> Despite these exclusions, the test does some reasonable verification work when MainThread is virtual.  This test historically cam in with a general "JVM monitoring and management API" change, it is not testing a particular fix.
> 
> 
> There's a failure condition in doCheck() which will not make the test fail: if it logs "TEST FAILED" in its final for loop, there is no failure.  Make the loop count the failures, and throw if there are any.
> 
> Also, while looking into this...  The variable names in some methods are confusing. In checkBlockedObject(), let's use "threadName" rather than "result" if we are finding a thread name, and let's not reuse the same result variable for a lockName later in the method.
> 
> The logs from this test are hard to read and verify, I find it better if the lock objects OBJB and OBJC are of classes other than Object, so you get to read, e.g.:
> LockAThread blocked on Locks$ObjectB at 4691fdfd
> (ObjectB, not just Object).

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/java/lang/management/ThreadMXBean/Locks.java
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14501/files
  - new: https://git.openjdk.org/jdk/pull/14501/files/c2e2a5b6..7bd08854

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14501&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14501&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14501.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14501/head:pull/14501

PR: https://git.openjdk.org/jdk/pull/14501

From kevinw at openjdk.org  Wed Jun 21 13:32:07 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 21 Jun 2023 13:32:07 GMT
Subject: RFR: 8306446: java/lang/management/ThreadMXBean/Locks.java
 transient failures [v2]
In-Reply-To: <7k4nEEHLK8O2r5IKZwfAMWOpyDO6FCLNvFX71MZPeVY=.6f93e611-3844-480e-b189-c97a3ef1900c@github.com>
References: <yJLcr84uu61lDSWtJkQy1FptnlzMKpsWs1HEuO9idPQ=.938810ca-26ec-4ed1-83f6-f59a01a25d47@github.com>
 <eKqqUTcodBti-_j8Z0IeiBZgR22KxgRW3Tgqo6eUG4U=.13656319-41e8-4c15-b382-6841db6ed341@github.com>
 <V_cUYaGMH73KRkS8-egv6p9KDAKKkg16qBwK3hUdXJc=.735b1b8f-342f-451f-ac09-cfcc45d8dbfc@github.com>
 <7k4nEEHLK8O2r5IKZwfAMWOpyDO6FCLNvFX71MZPeVY=.6f93e611-3844-480e-b189-c97a3ef1900c@github.com>
Message-ID: <qOjDXq89LhW9BOI7OHu2OR158_ENjvOEb92ltpShi-A=.4e8cdf76-6df4-4386-b083-ebfc94e36eff@github.com>

On Wed, 21 Jun 2023 12:54:06 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> ThreadMXBean::getAllThreadsIds returns an array of the thread IDs of platform threads, it doesn't include virtual threads, so I don't know why this filter is added.
>
> Whitespace correction, thanks.

The filter was because of a failure where it's called on a real thread that happens to own a VirtualThread lock, like:

"ForkJoinPool-1-worker-1" daemon prio=5 Id=32 WAITING on java.lang.VirtualThread at 289cb0b4 owned by "MainThread" Id=31

...actually my comment at line 67 isn't exactly correct, will update it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14501#discussion_r1236959285

From duke at openjdk.org  Wed Jun 21 13:36:08 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Wed, 21 Jun 2023 13:36:08 GMT
Subject: RFR: 8309979: BootstrapMethods attribute is missing in class files
 recreated by SA [v2]
In-Reply-To: <wPJDcnIRp7n6ysns1roSDQMM_Z448k6g74sT6g7-QuM=.2456dc2d-55ef-49e6-98ed-26efb1019ca6@github.com>
References: <nSooA6CtKm8LsaxzYdqJ6mtVV0os-kT5F2xNvYI4lJo=.c27bd28e-88d3-4bcb-ac3d-9036140eeff0@github.com>
 <i3PjGx_wbQ63SlwcWL5eBr28sDUb1_dPQ8Q0P3Qgzds=.5f11a8e5-714c-45c0-87e6-e612bb50b28b@github.com>
 <wPJDcnIRp7n6ysns1roSDQMM_Z448k6g74sT6g7-QuM=.2456dc2d-55ef-49e6-98ed-26efb1019ca6@github.com>
Message-ID: <hg07H2Wp0YStIWiFZNmmOLSap2OJgNQAfhSHGkI5Vcs=.7e1930c7-4e3b-4f51-8ad5-05bcaa65891a@github.com>

On Wed, 21 Jun 2023 12:47:10 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments by plummercj
>>   
>>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java line 756:
> 
>> 754:                 }
>> 755:             }
>> 756:         }
> 
> Hi, it looks odd to me that we only write one short in the loop: should that be a bootstrap method ref, num arguments, and arguments?
> 
> I was comparing with: https://docs.oracle.com/javase/specs/jvms/se20/jvms20.pdf
> 4.7.23 The BootstrapMethods Attribute
> 
> We have bootstrap attribute written by other code, e.g.
> "src/jdk.jdeps/share/classes/com/sun/tools/classfile/ClassWriter.java" 
> visitBootstrapMethods
> 
> "src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java" 
> writeBootstrapMethods

This is because the array returned by getBootstrapMethodAt() includes bootstrap method ref, num arguments and arguments. getBootstrapMethodAt() gets all the pieces and assembles them in the array which is then written out in this loop. There is already getBootstrapSpecifierAt() which is doing the same thing. So I just reused that implementation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14495#discussion_r1237011431

From lucy at openjdk.org  Wed Jun 21 15:22:05 2023
From: lucy at openjdk.org (Lutz Schmidt)
Date: Wed, 21 Jun 2023 15:22:05 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work
In-Reply-To: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
Message-ID: <n8JJ3yH2Oc3GZUEfGFN3zo-LOUyiDsf9UkMLHXaC8V8=.0bdb56e4-09cc-4501-a7ae-406f036e68d9@github.com>

On Tue, 20 Jun 2023 13:23:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
> But without the entitlement, a core is not generated.

LGTM.
Thanks for enhancing test analysis.

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

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14562#pullrequestreview-1491050558

From mbaesken at openjdk.org  Wed Jun 21 15:26:16 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 21 Jun 2023 15:26:16 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar
Message-ID: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>

There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted.

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

Commit messages:
 - JDK-8310550

Changes: https://git.openjdk.org/jdk/pull/14593/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14593&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310550
  Stats: 14 lines in 12 files changed: 0 ins; 7 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/14593.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14593/head:pull/14593

PR: https://git.openjdk.org/jdk/pull/14593

From clanger at openjdk.org  Wed Jun 21 15:29:21 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 21 Jun 2023 15:29:21 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work
In-Reply-To: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
Message-ID: <P0OBubziQAeWtqlOFA7qMWjTCxZtkPgDNqD1mt2OSWk=.85ab4ce6-dc69-43c4-b32f-8e0b6b850b2b@github.com>

On Tue, 20 Jun 2023 13:23:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
> But without the entitlement, a core is not generated.

I made a few review suggestions. Does the symptom happen on both, arm64 and x64?

test/lib/jdk/test/lib/Platform.java line 267:

> 265:         // Find the path to the java binary.
> 266:         String jdkPath = System.getProperty("java.home");
> 267:         Path javaPath = Paths.get(jdkPath + "/bin/java");

You could do it more concisely:

Path javaPath = Paths.get(System.getProperty("java.home") + "/bin/java");
if (Files.notExists(javaPath)) {
    throw new FileNotFoundException("Could not find file " + javaPath.toAbsolutePath().toString());

test/lib/jdk/test/lib/Platform.java line 274:

> 272: 
> 273:         // Run codesign on the java binary.
> 274:         ProcessBuilder pb = new ProcessBuilder("codesign", "--display", "--verbose", javaFileName);

And then here 'ProcessBuilder pb = new ProcessBuilder("codesign", "--display", "--verbose", javaPath.toAbsolutePath().toString());`

test/lib/jdk/test/lib/Platform.java line 277:

> 275:         pb.redirectErrorStream(true); // redirect stderr to stdout
> 276:         Process codesignProcess = pb.start();
> 277:         BufferedReader is = new BufferedReader(new InputStreamReader(codesignProcess.getInputStream()));

Maybe do the BufferedReader stuff in a try-with-resources and then return false instead of potentially throwing an IOException?

test/lib/jdk/test/lib/Platform.java line 280:

> 278:         String line;
> 279:         while ((line = is.readLine()) != null) {
> 280:             System.out.println("STDOUT: " + line);

This output is for every line seems too much. Maybe just print the lines where you find "Info.plist=not bound" or "Info.plist entries="?

test/lib/jdk/test/lib/util/CoreUtils.java line 153:

> 151:                     throw new SkippedException("Cannot produce core file with hardened binary on OSX 10.15 and later");
> 152:                 }
> 153:             } else {

Maybe you could do just one case here:
`else if (!Platform.hasPlistEntriesOSX()) {`...

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

PR Review: https://git.openjdk.org/jdk/pull/14562#pullrequestreview-1491050995
PR Review Comment: https://git.openjdk.org/jdk/pull/14562#discussion_r1237190071
PR Review Comment: https://git.openjdk.org/jdk/pull/14562#discussion_r1237190832
PR Review Comment: https://git.openjdk.org/jdk/pull/14562#discussion_r1237191976
PR Review Comment: https://git.openjdk.org/jdk/pull/14562#discussion_r1237194492
PR Review Comment: https://git.openjdk.org/jdk/pull/14562#discussion_r1237184922

From kevinw at openjdk.org  Wed Jun 21 16:42:05 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 21 Jun 2023 16:42:05 GMT
Subject: RFR: 8309979: BootstrapMethods attribute is missing in class files
 recreated by SA [v2]
In-Reply-To: <hg07H2Wp0YStIWiFZNmmOLSap2OJgNQAfhSHGkI5Vcs=.7e1930c7-4e3b-4f51-8ad5-05bcaa65891a@github.com>
References: <nSooA6CtKm8LsaxzYdqJ6mtVV0os-kT5F2xNvYI4lJo=.c27bd28e-88d3-4bcb-ac3d-9036140eeff0@github.com>
 <i3PjGx_wbQ63SlwcWL5eBr28sDUb1_dPQ8Q0P3Qgzds=.5f11a8e5-714c-45c0-87e6-e612bb50b28b@github.com>
 <wPJDcnIRp7n6ysns1roSDQMM_Z448k6g74sT6g7-QuM=.2456dc2d-55ef-49e6-98ed-26efb1019ca6@github.com>
 <hg07H2Wp0YStIWiFZNmmOLSap2OJgNQAfhSHGkI5Vcs=.7e1930c7-4e3b-4f51-8ad5-05bcaa65891a@github.com>
Message-ID: <BXnSz2srD8A_3JhCKPaTPKSEkUqRoT7yR2Y8ohltIBk=.c6157c8a-f5b5-4986-b4e1-16495d641df6@github.com>

On Wed, 21 Jun 2023 13:32:55 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java line 756:
>> 
>>> 754:                 }
>>> 755:             }
>>> 756:         }
>> 
>> Hi, it looks odd to me that we only write one short in the loop: should that be a bootstrap method ref, num arguments, and arguments?
>> 
>> I was comparing with: https://docs.oracle.com/javase/specs/jvms/se20/jvms20.pdf
>> 4.7.23 The BootstrapMethods Attribute
>> 
>> We have bootstrap attribute written by other code, e.g.
>> "src/jdk.jdeps/share/classes/com/sun/tools/classfile/ClassWriter.java" 
>> visitBootstrapMethods
>> 
>> "src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java" 
>> writeBootstrapMethods
>
> This is because the array returned by getBootstrapMethodAt() includes bootstrap method ref, num arguments and arguments. getBootstrapMethodAt() gets all the pieces and assembles them in the array which is then written out in this loop. There is already getBootstrapSpecifierAt() which is doing the same thing. So I just reused that implementation.

ah yes thanks, hadn't got there yet 8-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14495#discussion_r1237293582

From kevinw at openjdk.org  Wed Jun 21 16:46:03 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 21 Jun 2023 16:46:03 GMT
Subject: RFR: 8309979: BootstrapMethods attribute is missing in class files
 recreated by SA [v2]
In-Reply-To: <i3PjGx_wbQ63SlwcWL5eBr28sDUb1_dPQ8Q0P3Qgzds=.5f11a8e5-714c-45c0-87e6-e612bb50b28b@github.com>
References: <nSooA6CtKm8LsaxzYdqJ6mtVV0os-kT5F2xNvYI4lJo=.c27bd28e-88d3-4bcb-ac3d-9036140eeff0@github.com>
 <i3PjGx_wbQ63SlwcWL5eBr28sDUb1_dPQ8Q0P3Qgzds=.5f11a8e5-714c-45c0-87e6-e612bb50b28b@github.com>
Message-ID: <1VdW3S3qAoVFKe0ggKiPVlQcz9ecX0PqWkg7kqdQY0I=.3dc28805-1bd0-4db3-9884-8e8dd2203042@github.com>

On Thu, 15 Jun 2023 20:24:39 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> Please review this PR that extends SA to write BootstrapMethods attribute when dumping the class files.
>> 
>> Tested it by dumping the class file for java/lang/String and comparing the BootstrapMethods attribute shown by javap for the original and the dumped class.
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments by plummercj
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

Yes, I think it looks good. 8-)

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

PR Review: https://git.openjdk.org/jdk/pull/14495#pullrequestreview-1491234067

From kevinw at openjdk.org  Wed Jun 21 16:56:08 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 21 Jun 2023 16:56:08 GMT
Subject: RFR: 8306446: java/lang/management/ThreadMXBean/Locks.java
 transient failures [v3]
In-Reply-To: <yJLcr84uu61lDSWtJkQy1FptnlzMKpsWs1HEuO9idPQ=.938810ca-26ec-4ed1-83f6-f59a01a25d47@github.com>
References: <yJLcr84uu61lDSWtJkQy1FptnlzMKpsWs1HEuO9idPQ=.938810ca-26ec-4ed1-83f6-f59a01a25d47@github.com>
Message-ID: <sP587FPJLXH0m0QYOypszGvBG56TfaN2IY_XrdH6D9w=.42eb7e66-749b-4d9a-bde9-32f0c07a594c@github.com>

> This test iterates an array of ThreadInfos in a few places (e.g. in the method doCheck()), and needs to tolerate and ignore nulls, in case a thread finishes and the test hits an NPE.
> 
> There are other calls like "TM.getThreadInfo(tid).getLockName()" which might often be risky, but if the threads are blocked as they are here, they can't be terminating, so this usage is safe.
> 
> 
> The test has additional problems when started in a virtual thread.  ThreadMXBean.getThreadInfo() methods only return a ThreadInfo for platform threads.  The test needs to avoid some checks if mainThread is virtual.
> 
> In assertNoLock, it needs to not object to a thread holding a lock on a VirtualThread object is not relevant.
> Also the loop in doChecks which follows a chain of locks... This needs to recognise that ForkJoinPool thead is not worth pursuing.  It's not one of the very narrow set of threads this test cares about.
> 
> Despite these exclusions, the test does some reasonable verification work when MainThread is virtual.  This test historically cam in with a general "JVM monitoring and management API" change, it is not testing a particular fix.
> 
> 
> There's a failure condition in doCheck() which will not make the test fail: if it logs "TEST FAILED" in its final for loop, there is no failure.  Make the loop count the failures, and throw if there are any.
> 
> Also, while looking into this...  The variable names in some methods are confusing. In checkBlockedObject(), let's use "threadName" rather than "result" if we are finding a thread name, and let's not reuse the same result variable for a lockName later in the method.
> 
> The logs from this test are hard to read and verify, I find it better if the lock objects OBJB and OBJC are of classes other than Object, so you get to read, e.g.:
> LockAThread blocked on Locks$ObjectB at 4691fdfd
> (ObjectB, not just Object).

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  Comment update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14501/files
  - new: https://git.openjdk.org/jdk/pull/14501/files/7bd08854..3e09f14e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14501&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14501&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14501.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14501/head:pull/14501

PR: https://git.openjdk.org/jdk/pull/14501

From erikj at openjdk.org  Wed Jun 21 17:01:04 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 21 Jun 2023 17:01:04 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar
In-Reply-To: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
Message-ID: <wNaBmeQdT388fGPZljNxxG_k4sROzgMRPxAN90lq4_Q=.c3057546-4179-4745-b99b-73d740091d5b@github.com>

On Wed, 21 Jun 2023 15:18:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted.

The update to Java.gmk is good.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14593#pullrequestreview-1491263836

From sspitsyn at openjdk.org  Wed Jun 21 17:08:03 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 21 Jun 2023 17:08:03 GMT
Subject: [jdk21] RFR: 8308499: Test
 vmTestbase/nsk/jdi/MethodExitRequest/addClassExclusionFilter/filter001/TestDescription.java
 failed: VMDisconnectedException
In-Reply-To: <v4xIOmW5F8629A8LjZvdfLnOB-ZBodA8BcvJ0eVxr4E=.509f3cac-7309-405b-80af-eb6228b56bd4@github.com>
References: <v4xIOmW5F8629A8LjZvdfLnOB-ZBodA8BcvJ0eVxr4E=.509f3cac-7309-405b-80af-eb6228b56bd4@github.com>
Message-ID: <WboulYLx3Joblavo1g2srA8WecafDUcInVKXwP8G1kw=.5457953e-1512-4870-afc3-9aa76694ed36@github.com>

On Tue, 20 Jun 2023 18:25:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Clean backport of [JDK-8308499](https://bugs.openjdk.org/browse/JDK-8308499)

The backport is clean.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/41#pullrequestreview-1491278427

From cjplummer at openjdk.org  Wed Jun 21 17:16:10 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 21 Jun 2023 17:16:10 GMT
Subject: [jdk21] RFR: 8308499: Test
 vmTestbase/nsk/jdi/MethodExitRequest/addClassExclusionFilter/filter001/TestDescription.java
 failed: VMDisconnectedException
In-Reply-To: <v4xIOmW5F8629A8LjZvdfLnOB-ZBodA8BcvJ0eVxr4E=.509f3cac-7309-405b-80af-eb6228b56bd4@github.com>
References: <v4xIOmW5F8629A8LjZvdfLnOB-ZBodA8BcvJ0eVxr4E=.509f3cac-7309-405b-80af-eb6228b56bd4@github.com>
Message-ID: <RvcmiBhMNlaQ7OBEVX8IxchqSc5wd0TdBpNIY7n1-kI=.6974e322-d489-4c63-b1b8-df32abd751b5@github.com>

On Tue, 20 Jun 2023 18:25:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Clean backport of [JDK-8308499](https://bugs.openjdk.org/browse/JDK-8308499)

Thanks for the reviews Kevin and Serguei!

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

PR Comment: https://git.openjdk.org/jdk21/pull/41#issuecomment-1601256842

From cjplummer at openjdk.org  Wed Jun 21 17:16:12 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 21 Jun 2023 17:16:12 GMT
Subject: [jdk21] Integrated: 8308499: Test
 vmTestbase/nsk/jdi/MethodExitRequest/addClassExclusionFilter/filter001/TestDescription.java
 failed: VMDisconnectedException
In-Reply-To: <v4xIOmW5F8629A8LjZvdfLnOB-ZBodA8BcvJ0eVxr4E=.509f3cac-7309-405b-80af-eb6228b56bd4@github.com>
References: <v4xIOmW5F8629A8LjZvdfLnOB-ZBodA8BcvJ0eVxr4E=.509f3cac-7309-405b-80af-eb6228b56bd4@github.com>
Message-ID: <uIlZjfQM_9WIuh8Wtm4CFGtszw6Zlni_cUeAHu7ttus=.90ea6d01-9748-430f-b1c3-8b63e150b2d2@github.com>

On Tue, 20 Jun 2023 18:25:02 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Clean backport of [JDK-8308499](https://bugs.openjdk.org/browse/JDK-8308499)

This pull request has now been integrated.

Changeset: 722b512c
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/722b512c40e63af2f91a45a7f9eed67f1f9d35e2
Stats:     7 lines in 1 file changed: 5 ins; 0 del; 2 mod

8308499: Test vmTestbase/nsk/jdi/MethodExitRequest/addClassExclusionFilter/filter001/TestDescription.java failed: VMDisconnectedException

Reviewed-by: kevinw, sspitsyn
Backport-of: 79ff72a7762deb6010b57e5ac0ccede3d035ab4c

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

PR: https://git.openjdk.org/jdk21/pull/41

From sspitsyn at openjdk.org  Wed Jun 21 17:25:06 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 21 Jun 2023 17:25:06 GMT
Subject: [jdk21] RFR: Backport f91e9ba
In-Reply-To: <PzhO6iHSzQRBnKp_ElR_slY7sqVMzsgwfsHI3IMaiOQ=.d57a3477-cb32-4ae8-a6a4-cdb09749517e@github.com>
References: <PzhO6iHSzQRBnKp_ElR_slY7sqVMzsgwfsHI3IMaiOQ=.d57a3477-cb32-4ae8-a6a4-cdb09749517e@github.com>
Message-ID: <m0XYJ3Dqxv-kSJtlAT_iAOyY9LuQVLXvc2Da98WGJ7g=.854cb78b-8fd9-4820-8fec-b0a59a29998d@github.com>

On Wed, 21 Jun 2023 02:07:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Clean backport from latest jdk repo to jdk21 for the fix of:
>   8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING
> 
> Testing:
>  - TBD: mach5 tiers 1-5

> NOTE: if you change the PR title to `Backport COMMITHASH` as suggested by Skara in the **Issue** section of the PR description, Skara will be able to verify whether the backport is clean, and also mark it as a Backport.

Thank you, Kevin. It seems, I've done a typical mistake.

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

PR Comment: https://git.openjdk.org/jdk21/pull/43#issuecomment-1601280898

From kcr at openjdk.org  Wed Jun 21 18:00:11 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 21 Jun 2023 18:00:11 GMT
Subject: [jdk21] RFR: Backport f91e9ba
In-Reply-To: <PzhO6iHSzQRBnKp_ElR_slY7sqVMzsgwfsHI3IMaiOQ=.d57a3477-cb32-4ae8-a6a4-cdb09749517e@github.com>
References: <PzhO6iHSzQRBnKp_ElR_slY7sqVMzsgwfsHI3IMaiOQ=.d57a3477-cb32-4ae8-a6a4-cdb09749517e@github.com>
Message-ID: <zfZkmYtQBuDON0V8OP0VWQUk_EBybNx05R_yxZHZ8IA=.721fa4f7-9812-4621-9451-f016044b3340@github.com>

On Wed, 21 Jun 2023 02:07:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Clean backport from latest jdk repo to jdk21 for the fix of:
>   8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING
> 
> Testing:
>  - TBD: mach5 tiers 1-5

It needs to be the full 40 character hash.

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

PR Comment: https://git.openjdk.org/jdk21/pull/43#issuecomment-1601324622

From sspitsyn at openjdk.org  Wed Jun 21 18:13:06 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 21 Jun 2023 18:13:06 GMT
Subject: [jdk21] RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on
 carrier should return STATE_WAITING
In-Reply-To: <zfZkmYtQBuDON0V8OP0VWQUk_EBybNx05R_yxZHZ8IA=.721fa4f7-9812-4621-9451-f016044b3340@github.com>
References: <PzhO6iHSzQRBnKp_ElR_slY7sqVMzsgwfsHI3IMaiOQ=.d57a3477-cb32-4ae8-a6a4-cdb09749517e@github.com>
 <zfZkmYtQBuDON0V8OP0VWQUk_EBybNx05R_yxZHZ8IA=.721fa4f7-9812-4621-9451-f016044b3340@github.com>
Message-ID: <mFbDM-eq4GXZQdY5CSEfE_3-I6c_MC6Ut6S_ymPtc6s=.2294ef79-becd-41b6-aee2-09059ac0e1d6@github.com>

On Wed, 21 Jun 2023 17:57:28 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> It needs to be the full 40 character hash.

Thanks! It helped now.

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

PR Comment: https://git.openjdk.org/jdk21/pull/43#issuecomment-1601341517

From cjplummer at openjdk.org  Wed Jun 21 19:30:09 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 21 Jun 2023 19:30:09 GMT
Subject: [jdk21] RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on
 carrier should return STATE_WAITING
In-Reply-To: <PzhO6iHSzQRBnKp_ElR_slY7sqVMzsgwfsHI3IMaiOQ=.d57a3477-cb32-4ae8-a6a4-cdb09749517e@github.com>
References: <PzhO6iHSzQRBnKp_ElR_slY7sqVMzsgwfsHI3IMaiOQ=.d57a3477-cb32-4ae8-a6a4-cdb09749517e@github.com>
Message-ID: <swD_qX4mwRXc_eCVIyRaFk3ialYhbl9bNiAo0C_v5WE=.c041a874-e117-4be0-ac95-a26c15a585f3@github.com>

On Wed, 21 Jun 2023 02:07:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Clean backport from latest jdk repo to jdk21 for the fix of:
>   8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING
> 
> Testing:
>  - TBD: mach5 tiers 1-5

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/43#pullrequestreview-1491680730

From cjplummer at openjdk.org  Wed Jun 21 19:47:09 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 21 Jun 2023 19:47:09 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work
In-Reply-To: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
Message-ID: <2hTz6Ylp5KA89yQymiGug9j251kWEWeEYKL01an3gqM=.b270bd6f-0c69-4bec-8a6b-b423dc6d70d9@github.com>

On Tue, 20 Jun 2023 13:23:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
> But without the entitlement, a core is not generated.

Copyrights need updating.

test/lib/jdk/test/lib/Platform.java line 264:

> 262: 
> 263: 
> 264:     public static boolean hasPlistEntriesOSX() throws IOException {

Almost all of this is replicated from `isHardenedOSX()`. I wonder if there is a way to do some sharing while still maintaining separate APIs. Combining them into one API might make it harder to understand the code. Maybe a `launchCodesign()` API that returns the BufferedReader would help.

test/lib/jdk/test/lib/Platform.java line 288:

> 286:             }
> 287:         }
> 288:         return false;

Probably would be good to log that no Info.plist entry was found.

test/lib/jdk/test/lib/util/CoreUtils.java line 131:

> 129:             return coreFileLocation; // success!
> 130:         } else {
> 131:             System.out.println("Core file not found, try to find a reason for this");

Suggestion:

            System.out.println("Core file not found. Trying to find a reason why...");

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

PR Review: https://git.openjdk.org/jdk/pull/14562#pullrequestreview-1491685114
PR Review Comment: https://git.openjdk.org/jdk/pull/14562#discussion_r1237602062
PR Review Comment: https://git.openjdk.org/jdk/pull/14562#discussion_r1237587271
PR Review Comment: https://git.openjdk.org/jdk/pull/14562#discussion_r1237590277

From sspitsyn at openjdk.org  Wed Jun 21 20:24:08 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 21 Jun 2023 20:24:08 GMT
Subject: [jdk21] RFR: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState on
 carrier should return STATE_WAITING
In-Reply-To: <PzhO6iHSzQRBnKp_ElR_slY7sqVMzsgwfsHI3IMaiOQ=.d57a3477-cb32-4ae8-a6a4-cdb09749517e@github.com>
References: <PzhO6iHSzQRBnKp_ElR_slY7sqVMzsgwfsHI3IMaiOQ=.d57a3477-cb32-4ae8-a6a4-cdb09749517e@github.com>
Message-ID: <k1npCCspuRa-1xVOTYttojCksruMipibDxq0uDhfPIQ=.a65e6dd8-212f-4c46-9500-8f526e1ba39f@github.com>

On Wed, 21 Jun 2023 02:07:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Clean backport from latest jdk repo to jdk21 for the fix of:
>   8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING
> 
> Testing:
>  - TBD: mach5 tiers 1-5

Thank you for review, Chris!

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

PR Comment: https://git.openjdk.org/jdk21/pull/43#issuecomment-1601617466

From cjplummer at openjdk.org  Wed Jun 21 20:29:04 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 21 Jun 2023 20:29:04 GMT
Subject: RFR: 8242152: SA does not include StackMapTables when dumping
 .class files
In-Reply-To: <pBErA6eLKjV5Ydj7YKeOTkHW4VvuaylzXSdt2-QG2PE=.d4b64495-fbfd-467b-ad70-448e71fb3b1b@github.com>
References: <pBErA6eLKjV5Ydj7YKeOTkHW4VvuaylzXSdt2-QG2PE=.d4b64495-fbfd-467b-ad70-448e71fb3b1b@github.com>
Message-ID: <3iIklvW-U_R0tduoc4TK1sVYOdbcqiWOmFqXWSabkEg=.c30136bd-a8f9-4ee7-b947-5c1a16d170d4@github.com>

On Tue, 20 Jun 2023 11:31:40 GMT, Daohan Qu <dqu at openjdk.org> wrote:

> This patch adds `StackMapTable` for the class files generated by `clhsdb`'s `buildreplayjars` command. This bug manifests itself during my diagnosing [JDK-8309751](https://bugs.openjdk.org/browse/JDK-8309751) and needs to be fixed first.
> 
> I have run jtreg test `tier1-3` of release build on x86 linux finding only one failure in `tier2` caused by [JDK-8309214](https://bugs.openjdk.org/browse/JDK-8309214). `jtreg:test/hotspot/jtreg/serviceability` and `jtreg:test/jdk/sun/tools/` also passed.

I made a couple of minor suggestions. Otherwise it looks good.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstMethod.java line 113:

> 111:   private static MetadataField constants;
> 112:   // Raw stackmap data for the method (#entries + entries)
> 113:   private static AddressField stackMapData;

I think putting the comment on the same line as the declaration would be better

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java line 173:

> 171:         // Code attributes
> 172:         Short stackMapTableIndex = utf8ToIndex.get("StackMapTable");
> 173:         _stackMapTableIndex = (stackMapTableIndex != null)?

Add a space before the `?`

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14556#pullrequestreview-1491764984
PR Review Comment: https://git.openjdk.org/jdk/pull/14556#discussion_r1237635649
PR Review Comment: https://git.openjdk.org/jdk/pull/14556#discussion_r1237637155

From cjplummer at openjdk.org  Wed Jun 21 20:42:04 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 21 Jun 2023 20:42:04 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work
In-Reply-To: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
Message-ID: <h6xqXB9Y9mE68Xmc0mgx8ILnrcukS2nxvWCaa2XCseE=.2bd1a494-ddec-4077-8ad4-28aa14f5c47f@github.com>

On Tue, 20 Jun 2023 13:23:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
> But without the entitlement, a core is not generated.

Copyrights need updating.

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

Changes requested by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14562#pullrequestreview-1491822264

From sspitsyn at openjdk.org  Wed Jun 21 20:46:03 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 21 Jun 2023 20:46:03 GMT
Subject: RFR: 8242152: SA does not include StackMapTables when dumping
 .class files
In-Reply-To: <pBErA6eLKjV5Ydj7YKeOTkHW4VvuaylzXSdt2-QG2PE=.d4b64495-fbfd-467b-ad70-448e71fb3b1b@github.com>
References: <pBErA6eLKjV5Ydj7YKeOTkHW4VvuaylzXSdt2-QG2PE=.d4b64495-fbfd-467b-ad70-448e71fb3b1b@github.com>
Message-ID: <jkUVgjhMvRZLwUztKEP4wOyczN0BIQ1LTDZxp2czEZQ=.a7763605-b6be-491c-8888-fcaa127874ab@github.com>

On Tue, 20 Jun 2023 11:31:40 GMT, Daohan Qu <dqu at openjdk.org> wrote:

> This patch adds `StackMapTable` for the class files generated by `clhsdb`'s `buildreplayjars` command. This bug manifests itself during my diagnosing [JDK-8309751](https://bugs.openjdk.org/browse/JDK-8309751) and needs to be fixed first.
> 
> I have run jtreg test `tier1-3` of release build on x86 linux finding only one failure in `tier2` caused by [JDK-8309214](https://bugs.openjdk.org/browse/JDK-8309214). `jtreg:test/hotspot/jtreg/serviceability` and `jtreg:test/jdk/sun/tools/` also passed.

This looks good in general.
I've posted one nit about formatting.
What test coverage does this update have?

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java line 639:

> 637:               for (int i = 0; i < stackMapData.length(); i++) {
> 638:                 dos.writeByte(stackMapData.at(i));
> 639:               }

The indent in this file is 8. So, it has to be 8 in fragments: 528-543 and 632-640.

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

PR Review: https://git.openjdk.org/jdk/pull/14556#pullrequestreview-1491831245
PR Review Comment: https://git.openjdk.org/jdk/pull/14556#discussion_r1237671930

From cjplummer at openjdk.org  Wed Jun 21 20:55:04 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 21 Jun 2023 20:55:04 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work
In-Reply-To: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
Message-ID: <3m7KbhMvjSVURD5Yaaa2uyZj1exZbaGym0OMR6Owwuw=.588185b3-b494-4fd0-9e6d-218da1155448@github.com>

On Tue, 20 Jun 2023 13:23:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
> But without the entitlement, a core is not generated.

`jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java` is failing due to the new API in Platform.java.

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

PR Comment: https://git.openjdk.org/jdk/pull/14562#issuecomment-1601655977

From dholmes at openjdk.org  Wed Jun 21 21:51:03 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 21 Jun 2023 21:51:03 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar
In-Reply-To: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
Message-ID: <RhyKQERReuok9CVTDMV57hGRtnfTtUnKMEWfVLKQepQ=.afa0d7fb-99a5-486d-83e1-db7cbfbf7ccf@github.com>

On Wed, 21 Jun 2023 15:18:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted.

Mostly seems okay - a couple of things need further adjusting I think.

Thanks.

src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java line 196:

> 194: 
> 195:     /**
> 196:      * Set whether or not to use ct.sym as an alternate

As an alternate to what? This needs something else.

test/langtools/tools/javap/4798312/JavapShouldLoadClassesFromRTJarTest.java line 1:

> 1: /*

The name of this test includes RTJar. It needs to be changed too I think. Does this test actually still test something?

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14593#pullrequestreview-1491961660
PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1237747922
PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1237749197

From dholmes at openjdk.org  Thu Jun 22 01:46:02 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 22 Jun 2023 01:46:02 GMT
Subject: RFR: 8306446: java/lang/management/ThreadMXBean/Locks.java
 transient failures [v3]
In-Reply-To: <sP587FPJLXH0m0QYOypszGvBG56TfaN2IY_XrdH6D9w=.42eb7e66-749b-4d9a-bde9-32f0c07a594c@github.com>
References: <yJLcr84uu61lDSWtJkQy1FptnlzMKpsWs1HEuO9idPQ=.938810ca-26ec-4ed1-83f6-f59a01a25d47@github.com>
 <sP587FPJLXH0m0QYOypszGvBG56TfaN2IY_XrdH6D9w=.42eb7e66-749b-4d9a-bde9-32f0c07a594c@github.com>
Message-ID: <zGKDknQD-6RpQfKA0E8VxfXFQKdM3FZLF82dmUuEYkc=.96b1ef20-0ad3-401b-8a08-b9775c1c9d62@github.com>

On Wed, 21 Jun 2023 16:56:08 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> This test iterates an array of ThreadInfos in a few places (e.g. in the method doCheck()), and needs to tolerate and ignore nulls, in case a thread finishes and the test hits an NPE.
>> 
>> There are other calls like "TM.getThreadInfo(tid).getLockName()" which might often be risky, but if the threads are blocked as they are here, they can't be terminating, so this usage is safe.
>> 
>> 
>> The test has additional problems when started in a virtual thread.  ThreadMXBean.getThreadInfo() methods only return a ThreadInfo for platform threads.  The test needs to avoid some checks if mainThread is virtual.
>> 
>> In assertNoLock, it needs to not object to a thread holding a lock on a VirtualThread object is not relevant.
>> Also the loop in doChecks which follows a chain of locks... This needs to recognise that ForkJoinPool thead is not worth pursuing.  It's not one of the very narrow set of threads this test cares about.
>> 
>> Despite these exclusions, the test does some reasonable verification work when MainThread is virtual.  This test historically cam in with a general "JVM monitoring and management API" change, it is not testing a particular fix.
>> 
>> 
>> There's a failure condition in doCheck() which will not make the test fail: if it logs "TEST FAILED" in its final for loop, there is no failure.  Make the loop count the failures, and throw if there are any.
>> 
>> Also, while looking into this...  The variable names in some methods are confusing. In checkBlockedObject(), let's use "threadName" rather than "result" if we are finding a thread name, and let's not reuse the same result variable for a lockName later in the method.
>> 
>> The logs from this test are hard to read and verify, I find it better if the lock objects OBJB and OBJC are of classes other than Object, so you get to read, e.g.:
>> LockAThread blocked on Locks$ObjectB at 4691fdfd
>> (ObjectB, not just Object).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment update

> In assertNoLock, it needs to not object to a thread holding a lock on a VirtualThread object is not relevant.

Can you elaborate on this please. I'm unclear how the test knows whether a thread may be holding any locks or not, but why is locking a VirtualThread instance a special case??

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

PR Comment: https://git.openjdk.org/jdk/pull/14501#issuecomment-1601900908

From dqu at openjdk.org  Thu Jun 22 02:37:08 2023
From: dqu at openjdk.org (Daohan Qu)
Date: Thu, 22 Jun 2023 02:37:08 GMT
Subject: RFR: 8242152: SA does not include StackMapTables when dumping
 .class files [v2]
In-Reply-To: <pBErA6eLKjV5Ydj7YKeOTkHW4VvuaylzXSdt2-QG2PE=.d4b64495-fbfd-467b-ad70-448e71fb3b1b@github.com>
References: <pBErA6eLKjV5Ydj7YKeOTkHW4VvuaylzXSdt2-QG2PE=.d4b64495-fbfd-467b-ad70-448e71fb3b1b@github.com>
Message-ID: <T0jXqjCNuSuj6EUr-MGNGkfUJLeqpziABJZvUhp9yYo=.9cfb47ca-ebcc-4422-8599-2ebdbe563e2f@github.com>

> This patch adds `StackMapTable` for the class files generated by `clhsdb`'s `buildreplayjars` command. This bug manifests itself during my diagnosing [JDK-8309751](https://bugs.openjdk.org/browse/JDK-8309751) and needs to be fixed first.
> 
> I have run jtreg test `tier1-3` of release build on x86 linux finding only one failure in `tier2` caused by [JDK-8309214](https://bugs.openjdk.org/browse/JDK-8309214). `jtreg:test/hotspot/jtreg/serviceability` and `jtreg:test/jdk/sun/tools/` also passed.

Daohan Qu has updated the pull request incrementally with one additional commit since the last revision:

  Fix some code format issues

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14556/files
  - new: https://git.openjdk.org/jdk/pull/14556/files/7b8a246d..f2d2340d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14556&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14556&range=00-01

  Stats: 20 lines in 2 files changed: 0 ins; 1 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/14556.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14556/head:pull/14556

PR: https://git.openjdk.org/jdk/pull/14556

From dqu at openjdk.org  Thu Jun 22 02:37:11 2023
From: dqu at openjdk.org (Daohan Qu)
Date: Thu, 22 Jun 2023 02:37:11 GMT
Subject: RFR: 8242152: SA does not include StackMapTables when dumping
 .class files [v2]
In-Reply-To: <3iIklvW-U_R0tduoc4TK1sVYOdbcqiWOmFqXWSabkEg=.c30136bd-a8f9-4ee7-b947-5c1a16d170d4@github.com>
References: <pBErA6eLKjV5Ydj7YKeOTkHW4VvuaylzXSdt2-QG2PE=.d4b64495-fbfd-467b-ad70-448e71fb3b1b@github.com>
 <3iIklvW-U_R0tduoc4TK1sVYOdbcqiWOmFqXWSabkEg=.c30136bd-a8f9-4ee7-b947-5c1a16d170d4@github.com>
Message-ID: <7ne3Y0XASPA-4YoQCV2v5btnWtkT2xG7750YD_wpVIw=.92e5b001-dca5-4b4b-9501-0ce14aca7e8b@github.com>

On Wed, 21 Jun 2023 20:19:59 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Daohan Qu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix some code format issues
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstMethod.java line 113:
> 
>> 111:   private static MetadataField constants;
>> 112:   // Raw stackmap data for the method (#entries + entries)
>> 113:   private static AddressField stackMapData;
> 
> I think putting the comment on the same line as the declaration would be better

Ok

> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java line 173:
> 
>> 171:         // Code attributes
>> 172:         Short stackMapTableIndex = utf8ToIndex.get("StackMapTable");
>> 173:         _stackMapTableIndex = (stackMapTableIndex != null)?
> 
> Add a space before the `?`

Ok

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14556#discussion_r1237920892
PR Review Comment: https://git.openjdk.org/jdk/pull/14556#discussion_r1237921127

From dqu at openjdk.org  Thu Jun 22 02:37:14 2023
From: dqu at openjdk.org (Daohan Qu)
Date: Thu, 22 Jun 2023 02:37:14 GMT
Subject: RFR: 8242152: SA does not include StackMapTables when dumping
 .class files [v2]
In-Reply-To: <jkUVgjhMvRZLwUztKEP4wOyczN0BIQ1LTDZxp2czEZQ=.a7763605-b6be-491c-8888-fcaa127874ab@github.com>
References: <pBErA6eLKjV5Ydj7YKeOTkHW4VvuaylzXSdt2-QG2PE=.d4b64495-fbfd-467b-ad70-448e71fb3b1b@github.com>
 <jkUVgjhMvRZLwUztKEP4wOyczN0BIQ1LTDZxp2czEZQ=.a7763605-b6be-491c-8888-fcaa127874ab@github.com>
Message-ID: <qeVGJHYFmC69yVe1LUVyZKj_k_5EIEbQTYpcLarc98o=.467c07ac-8418-4b4a-9a3e-1330d546f924@github.com>

On Wed, 21 Jun 2023 20:42:04 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Daohan Qu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix some code format issues
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java line 639:
> 
>> 637:               for (int i = 0; i < stackMapData.length(); i++) {
>> 638:                 dos.writeByte(stackMapData.at(i));
>> 639:               }
> 
> The indent in this file is 8. So, it has to be 8 in fragments: 528-543 and 632-640.

Good catch! Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14556#discussion_r1237921778

From dqu at openjdk.org  Thu Jun 22 02:59:05 2023
From: dqu at openjdk.org (Daohan Qu)
Date: Thu, 22 Jun 2023 02:59:05 GMT
Subject: RFR: 8242152: SA does not include StackMapTables when dumping
 .class files [v2]
In-Reply-To: <3iIklvW-U_R0tduoc4TK1sVYOdbcqiWOmFqXWSabkEg=.c30136bd-a8f9-4ee7-b947-5c1a16d170d4@github.com>
References: <pBErA6eLKjV5Ydj7YKeOTkHW4VvuaylzXSdt2-QG2PE=.d4b64495-fbfd-467b-ad70-448e71fb3b1b@github.com>
 <3iIklvW-U_R0tduoc4TK1sVYOdbcqiWOmFqXWSabkEg=.c30136bd-a8f9-4ee7-b947-5c1a16d170d4@github.com>
Message-ID: <mIxGv0jCBRkVclKAC915592dtzKf8Zz_atS4WamFHAc=.113804b0-8d2a-4b83-8343-218acaa84154@github.com>

On Wed, 21 Jun 2023 20:26:20 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Daohan Qu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix some code format issues
>
> I made a couple of minor suggestions. Otherwise it looks good.

Thank @plummercj and @sspitsyn  for your reviews! 

> What test coverage does this update have?

AFAICS, there are two jtreg tests for class dump ? one is [`test/hotspot/jtreg/serviceability/sa/ClhsdbDumpclass.java`](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/serviceability/sa/ClhsdbDumpclass.java) and another is [`test/hotspot/jtreg/serviceability/sa/TestClassDump.java`](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/serviceability/sa/TestClassDump.java). The former invoke `javap` on the generated class file to see if it is valid class file while the later directly "invoke" `sun.jvm.hotspot.tools.jcore.ClassDump` to see if it runs without exception.

Maybe we could add a validation in `ClhsdbDumpclass.java` to ensure that the generated class file contains some `StackMapTable`s? (As the class under validation `LingeredApp` should has `StackMapTable`s for some methods.)

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

PR Comment: https://git.openjdk.org/jdk/pull/14556#issuecomment-1601946451

From sspitsyn at openjdk.org  Thu Jun 22 03:24:06 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 22 Jun 2023 03:24:06 GMT
Subject: RFR: 8309979: BootstrapMethods attribute is missing in class files
 recreated by SA [v2]
In-Reply-To: <i3PjGx_wbQ63SlwcWL5eBr28sDUb1_dPQ8Q0P3Qgzds=.5f11a8e5-714c-45c0-87e6-e612bb50b28b@github.com>
References: <nSooA6CtKm8LsaxzYdqJ6mtVV0os-kT5F2xNvYI4lJo=.c27bd28e-88d3-4bcb-ac3d-9036140eeff0@github.com>
 <i3PjGx_wbQ63SlwcWL5eBr28sDUb1_dPQ8Q0P3Qgzds=.5f11a8e5-714c-45c0-87e6-e612bb50b28b@github.com>
Message-ID: <BcYUruTksAAC-JjG4G97NDGp-757WOzZgZjfjJjg2LA=.9e7ef15b-b1cf-430f-85cb-c9ca06576b96@github.com>

On Thu, 15 Jun 2023 20:24:39 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> Please review this PR that extends SA to write BootstrapMethods attribute when dumping the class files.
>> 
>> Tested it by dumping the class file for java/lang/String and comparing the BootstrapMethods attribute shown by javap for the original and the dumped class.
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments by plummercj
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

Looks good in general.
Just a question: Do we have any automatic test coverage for this?
Thanks,
Serguei

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPool.java line 475:

> 473:     if (operands != null) {
> 474:       count = getOperandOffsetAt(operands, 0) / 2;
> 475:     }

Nit: Could you, please, add a small comment why the bootstrap methods count is calculated this way?

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

PR Review: https://git.openjdk.org/jdk/pull/14495#pullrequestreview-1492282704
PR Review Comment: https://git.openjdk.org/jdk/pull/14495#discussion_r1237945025

From sspitsyn at openjdk.org  Thu Jun 22 03:27:03 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 22 Jun 2023 03:27:03 GMT
Subject: RFR: 8242152: SA does not include StackMapTables when dumping
 .class files [v2]
In-Reply-To: <mIxGv0jCBRkVclKAC915592dtzKf8Zz_atS4WamFHAc=.113804b0-8d2a-4b83-8343-218acaa84154@github.com>
References: <pBErA6eLKjV5Ydj7YKeOTkHW4VvuaylzXSdt2-QG2PE=.d4b64495-fbfd-467b-ad70-448e71fb3b1b@github.com>
 <3iIklvW-U_R0tduoc4TK1sVYOdbcqiWOmFqXWSabkEg=.c30136bd-a8f9-4ee7-b947-5c1a16d170d4@github.com>
 <mIxGv0jCBRkVclKAC915592dtzKf8Zz_atS4WamFHAc=.113804b0-8d2a-4b83-8343-218acaa84154@github.com>
Message-ID: <ujRwKS3XanQymlvbTg_So0VoprU9w7ByWtGmQHQcUFs=.18aec22c-8096-47ee-9207-d5774b91185b@github.com>

On Thu, 22 Jun 2023 02:55:47 GMT, Daohan Qu <dqu at openjdk.org> wrote:

> Maybe we could add a validation in `ClhsdbDumpclass.java` to ensure that the generated class file contains some `StackMapTable`s? (As the class under validation `LingeredApp` should has `StackMapTable`s for some methods.)

It would be nice to add if it is not hard.
Thank you for the answers.

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

PR Comment: https://git.openjdk.org/jdk/pull/14556#issuecomment-1601961792

From sspitsyn at openjdk.org  Thu Jun 22 03:32:03 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 22 Jun 2023 03:32:03 GMT
Subject: RFR: 8242152: SA does not include StackMapTables when dumping
 .class files [v2]
In-Reply-To: <T0jXqjCNuSuj6EUr-MGNGkfUJLeqpziABJZvUhp9yYo=.9cfb47ca-ebcc-4422-8599-2ebdbe563e2f@github.com>
References: <pBErA6eLKjV5Ydj7YKeOTkHW4VvuaylzXSdt2-QG2PE=.d4b64495-fbfd-467b-ad70-448e71fb3b1b@github.com>
 <T0jXqjCNuSuj6EUr-MGNGkfUJLeqpziABJZvUhp9yYo=.9cfb47ca-ebcc-4422-8599-2ebdbe563e2f@github.com>
Message-ID: <0rk3mLU3IpvriFXEr1L-MZV3xLGQtVO4yC6G91vv1JA=.23c16e75-0717-4839-b0af-309cd9cbab79@github.com>

On Thu, 22 Jun 2023 02:37:08 GMT, Daohan Qu <dqu at openjdk.org> wrote:

>> This patch adds `StackMapTable` for the class files generated by `clhsdb`'s `buildreplayjars` command. This bug manifests itself during my diagnosing [JDK-8309751](https://bugs.openjdk.org/browse/JDK-8309751) and needs to be fixed first.
>> 
>> I have run jtreg test `tier1-3` of release build on x86 linux finding only one failure in `tier2` caused by [JDK-8309214](https://bugs.openjdk.org/browse/JDK-8309214). `jtreg:test/hotspot/jtreg/serviceability` and `jtreg:test/jdk/sun/tools/` also passed.
>
> Daohan Qu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix some code format issues

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14556#pullrequestreview-1492290569

From sspitsyn at openjdk.org  Thu Jun 22 03:32:05 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 22 Jun 2023 03:32:05 GMT
Subject: RFR: 8242152: SA does not include StackMapTables when dumping
 .class files [v2]
In-Reply-To: <mIxGv0jCBRkVclKAC915592dtzKf8Zz_atS4WamFHAc=.113804b0-8d2a-4b83-8343-218acaa84154@github.com>
References: <pBErA6eLKjV5Ydj7YKeOTkHW4VvuaylzXSdt2-QG2PE=.d4b64495-fbfd-467b-ad70-448e71fb3b1b@github.com>
 <3iIklvW-U_R0tduoc4TK1sVYOdbcqiWOmFqXWSabkEg=.c30136bd-a8f9-4ee7-b947-5c1a16d170d4@github.com>
 <mIxGv0jCBRkVclKAC915592dtzKf8Zz_atS4WamFHAc=.113804b0-8d2a-4b83-8343-218acaa84154@github.com>
Message-ID: <J6RyHD20Dwg1HXOdPNst8EFjNMX-LKtobaaUj5c0A4U=.b498db27-b7c9-49e6-a88f-6deccc71626a@github.com>

On Thu, 22 Jun 2023 02:55:47 GMT, Daohan Qu <dqu at openjdk.org> wrote:

> Maybe we could add a validation in `ClhsdbDumpclass.java` to ensure that the generated class file contains some `StackMapTable`s? (As the class under validation `LingeredApp` should has `StackMapTable`s for some methods.)

It'd be nice to add if it is not hard to do.
Thank you for the update and answer.

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

PR Comment: https://git.openjdk.org/jdk/pull/14556#issuecomment-1601963812

From sspitsyn at openjdk.org  Thu Jun 22 03:35:04 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 22 Jun 2023 03:35:04 GMT
Subject: [jdk21] Integrated: 8309612: [REDO] JDK-8307153 JVMTI GetThreadState
 on carrier should return STATE_WAITING
In-Reply-To: <PzhO6iHSzQRBnKp_ElR_slY7sqVMzsgwfsHI3IMaiOQ=.d57a3477-cb32-4ae8-a6a4-cdb09749517e@github.com>
References: <PzhO6iHSzQRBnKp_ElR_slY7sqVMzsgwfsHI3IMaiOQ=.d57a3477-cb32-4ae8-a6a4-cdb09749517e@github.com>
Message-ID: <-Xq0qh1MyUihVd97IkhJCLUKvMNt8fpBmNCVaS5e3zo=.1e189b64-859f-44d6-b09e-967202caaf7a@github.com>

On Wed, 21 Jun 2023 02:07:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Clean backport from latest jdk repo to jdk21 for the fix of:
>   8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING
> 
> Testing:
>  - TBD: mach5 tiers 1-5

This pull request has now been integrated.

Changeset: f8a38eec
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/f8a38eecc6796ff9671550d45677b06eba8c9372
Stats:     96 lines in 4 files changed: 76 ins; 0 del; 20 mod

8309612: [REDO] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING

Reviewed-by: cjplummer
Backport-of: f91e9ba757f04983655c23542e06973805465249

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

PR: https://git.openjdk.org/jdk21/pull/43

From dqu at openjdk.org  Thu Jun 22 04:00:14 2023
From: dqu at openjdk.org (Daohan Qu)
Date: Thu, 22 Jun 2023 04:00:14 GMT
Subject: RFR: 8242152: SA does not include StackMapTables when dumping
 .class files [v3]
In-Reply-To: <pBErA6eLKjV5Ydj7YKeOTkHW4VvuaylzXSdt2-QG2PE=.d4b64495-fbfd-467b-ad70-448e71fb3b1b@github.com>
References: <pBErA6eLKjV5Ydj7YKeOTkHW4VvuaylzXSdt2-QG2PE=.d4b64495-fbfd-467b-ad70-448e71fb3b1b@github.com>
Message-ID: <VnJD6sy-w0jZDFFK23NEl7hw82JzsLtazQTD4-zScmQ=.90b285d8-51b9-4bbb-920f-160eaf273ea4@github.com>

> This patch adds `StackMapTable` for the class files generated by `clhsdb`'s `buildreplayjars` command. This bug manifests itself during my diagnosing [JDK-8309751](https://bugs.openjdk.org/browse/JDK-8309751) and needs to be fixed first.
> 
> I have run jtreg test `tier1-3` of release build on x86 linux finding only one failure in `tier2` caused by [JDK-8309214](https://bugs.openjdk.org/browse/JDK-8309214). `jtreg:test/hotspot/jtreg/serviceability` and `jtreg:test/jdk/sun/tools/` also passed.

Daohan Qu has updated the pull request incrementally with one additional commit since the last revision:

  Add a simple check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14556/files
  - new: https://git.openjdk.org/jdk/pull/14556/files/f2d2340d..d28b785d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14556&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14556&range=01-02

  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14556.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14556/head:pull/14556

PR: https://git.openjdk.org/jdk/pull/14556

From dqu at openjdk.org  Thu Jun 22 04:00:16 2023
From: dqu at openjdk.org (Daohan Qu)
Date: Thu, 22 Jun 2023 04:00:16 GMT
Subject: RFR: 8242152: SA does not include StackMapTables when dumping
 .class files [v2]
In-Reply-To: <T0jXqjCNuSuj6EUr-MGNGkfUJLeqpziABJZvUhp9yYo=.9cfb47ca-ebcc-4422-8599-2ebdbe563e2f@github.com>
References: <pBErA6eLKjV5Ydj7YKeOTkHW4VvuaylzXSdt2-QG2PE=.d4b64495-fbfd-467b-ad70-448e71fb3b1b@github.com>
 <T0jXqjCNuSuj6EUr-MGNGkfUJLeqpziABJZvUhp9yYo=.9cfb47ca-ebcc-4422-8599-2ebdbe563e2f@github.com>
Message-ID: <zKEeSRYTdfyYulUNVSL6MzZLPTrY5fOgfdIWP-qiDAM=.c2da4c8c-3a8e-4869-aa1d-567482c84a4e@github.com>

On Thu, 22 Jun 2023 02:37:08 GMT, Daohan Qu <dqu at openjdk.org> wrote:

>> This patch adds `StackMapTable` for the class files generated by `clhsdb`'s `buildreplayjars` command. This bug manifests itself during my diagnosing [JDK-8309751](https://bugs.openjdk.org/browse/JDK-8309751) and needs to be fixed first.
>> 
>> I have run jtreg test `tier1-3` of release build on x86 linux finding only one failure in `tier2` caused by [JDK-8309214](https://bugs.openjdk.org/browse/JDK-8309214). `jtreg:test/hotspot/jtreg/serviceability` and `jtreg:test/jdk/sun/tools/` also passed.
>
> Daohan Qu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix some code format issues

A simple check has been added. For optional attributes like `StackMapTable`, a comprehensive check would involve comparing the original class file with the generated one. However, I believe that this deserves another PR.

FYI, `jtreg:test/hotspot/jtreg/serviceability` still passes.

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

PR Comment: https://git.openjdk.org/jdk/pull/14556#issuecomment-1601974520

From cjplummer at openjdk.org  Thu Jun 22 04:32:07 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 22 Jun 2023 04:32:07 GMT
Subject: RFR: 8242152: SA does not include StackMapTables when dumping
 .class files [v3]
In-Reply-To: <VnJD6sy-w0jZDFFK23NEl7hw82JzsLtazQTD4-zScmQ=.90b285d8-51b9-4bbb-920f-160eaf273ea4@github.com>
References: <pBErA6eLKjV5Ydj7YKeOTkHW4VvuaylzXSdt2-QG2PE=.d4b64495-fbfd-467b-ad70-448e71fb3b1b@github.com>
 <VnJD6sy-w0jZDFFK23NEl7hw82JzsLtazQTD4-zScmQ=.90b285d8-51b9-4bbb-920f-160eaf273ea4@github.com>
Message-ID: <CR-dGzhFu0KezQ3RWxoRW8W-PtakjCqxDsuqqKMffhk=.6743814a-417e-4844-8aea-5b598e86eef5@github.com>

On Thu, 22 Jun 2023 04:00:14 GMT, Daohan Qu <dqu at openjdk.org> wrote:

>> This patch adds `StackMapTable` for the class files generated by `clhsdb`'s `buildreplayjars` command. This bug manifests itself during my diagnosing [JDK-8309751](https://bugs.openjdk.org/browse/JDK-8309751) and needs to be fixed first.
>> 
>> I have run jtreg test `tier1-3` of release build on x86 linux finding only one failure in `tier2` caused by [JDK-8309214](https://bugs.openjdk.org/browse/JDK-8309214). `jtreg:test/hotspot/jtreg/serviceability` and `jtreg:test/jdk/sun/tools/` also passed.
>
> Daohan Qu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a simple check

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14556#pullrequestreview-1492330531

From cjplummer at openjdk.org  Thu Jun 22 04:35:02 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 22 Jun 2023 04:35:02 GMT
Subject: RFR: 8294316: SA core file support is broken on macosx-x64
 starting with macOS 12.x
In-Reply-To: <0wPtkRqjB3Nh6LiABARFcqq6UqcCsTNbF1ok1iG0Efw=.af55940f-5b2d-4cfb-b233-066a419bae48@github.com>
References: <0wPtkRqjB3Nh6LiABARFcqq6UqcCsTNbF1ok1iG0Efw=.af55940f-5b2d-4cfb-b233-066a419bae48@github.com>
Message-ID: <aww5nN1uEvwzUzFxX2izy_ewnFTNlJOvriQhuf-bnS8=.7ca30162-6e55-4de9-92cb-e3742d7dea92@github.com>

On Tue, 20 Jun 2023 18:05:09 GMT, Tom Rodriguez <never at openjdk.org> wrote:

> This is a minor fix to core file reading on macos x.  I can confirm that after this fix I can run the problem listed SA core file tests on Ventura.

Marked as reviewed by cjplummer (Reviewer).

src/jdk.hotspot.agent/macosx/native/libsaproc/ps_core.c line 309:

> 307:         print_debug("LC_SEGMENT_64 added: nsects=%d fileoff=0x%llx vmaddr=0x%llx vmsize=0x%llx filesize=0x%llx %s\n",
> 308:                     segcmd.nsects, segcmd.fileoff, segcmd.vmaddr, segcmd.vmsize,
> 309:                     segcmd.filesize, &segcmd.segname[0]);

It would be nice to include this print_debug for the `filesize == 0` case. Maybe you can move it outside of the `if` and print `added` or `skipped` conditional on `filesize`.

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

PR Review: https://git.openjdk.org/jdk/pull/14569#pullrequestreview-1491727136
PR Review Comment: https://git.openjdk.org/jdk/pull/14569#discussion_r1237613357

From sspitsyn at openjdk.org  Thu Jun 22 05:24:16 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 22 Jun 2023 05:24:16 GMT
Subject: RFR: 8309909: remove test nsk.jvmti test objmonusage006 from
 ProblemList-Virtual.txt
Message-ID: <H4jvWMeqkH1rAVrKUqCyMvg6QUVOWgniiZpPZojodeg=.a899ee8f-24b9-482b-b5fc-98a86a613ba6@github.com>

The following bug was closed as "Cannot Reproduce":
[8300709](https://bugs.openjdk.org/browse/JDK-8300709) nsk/jvmti/GetObjectMonitorUsage/objmonusage006 test asserts with virtual thread wrapper

I was not able to reproduce the assert in thousands mach5 runs on multiple debug builds.
Also, the original sources were significantly changed, so it is not clear anymore in what context the assert was fired.
The test is problem-listed in `ProblemList-Virtual.txt`.

This sub-task is to unproblem-list the test:
   `vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage006/TestDescription.java`
 
If the original asset is reproduced again then the plan is to reopen the [8300709](https://bugs.openjdk.org/browse/JDK-8300709) and update it with the details needed for issue investigation.

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

Commit messages:
 - 8309909: remove test nsk.jvmti test objmonusage006 from ProblemList-Virtual.txt

Changes: https://git.openjdk.org/jdk/pull/14610/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14610&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309909
  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14610.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14610/head:pull/14610

PR: https://git.openjdk.org/jdk/pull/14610

From cjplummer at openjdk.org  Thu Jun 22 05:24:17 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 22 Jun 2023 05:24:17 GMT
Subject: RFR: 8309909: remove test nsk.jvmti test objmonusage006 from
 ProblemList-Virtual.txt
In-Reply-To: <H4jvWMeqkH1rAVrKUqCyMvg6QUVOWgniiZpPZojodeg=.a899ee8f-24b9-482b-b5fc-98a86a613ba6@github.com>
References: <H4jvWMeqkH1rAVrKUqCyMvg6QUVOWgniiZpPZojodeg=.a899ee8f-24b9-482b-b5fc-98a86a613ba6@github.com>
Message-ID: <9bDnvw3VBjcPFU1xvpxfZ6qjfg7Goy9DNBJ2To8RAjs=.3d1c0f65-a8a5-4793-b109-e65161bf90d2@github.com>

On Thu, 22 Jun 2023 01:23:46 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The following bug was closed as "Cannot Reproduce":
> [8300709](https://bugs.openjdk.org/browse/JDK-8300709) nsk/jvmti/GetObjectMonitorUsage/objmonusage006 test asserts with virtual thread wrapper
> 
> I was not able to reproduce the assert in thousands mach5 runs on multiple debug builds.
> Also, the original sources were significantly changed, so it is not clear anymore in what context the assert was fired.
> The test is problem-listed in `ProblemList-Virtual.txt`.
> 
> This sub-task is to unproblem-list the test:
>    `vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage006/TestDescription.java`
>  
> If the original asset is reproduced again then the plan is to reopen the [8300709](https://bugs.openjdk.org/browse/JDK-8300709) and update it with the details needed for issue investigation.

Approved and trivial.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14610#pullrequestreview-1492370042

From sspitsyn at openjdk.org  Thu Jun 22 05:49:07 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 22 Jun 2023 05:49:07 GMT
Subject: RFR: 8309909: remove test nsk.jvmti test objmonusage006 from
 ProblemList-Virtual.txt
In-Reply-To: <H4jvWMeqkH1rAVrKUqCyMvg6QUVOWgniiZpPZojodeg=.a899ee8f-24b9-482b-b5fc-98a86a613ba6@github.com>
References: <H4jvWMeqkH1rAVrKUqCyMvg6QUVOWgniiZpPZojodeg=.a899ee8f-24b9-482b-b5fc-98a86a613ba6@github.com>
Message-ID: <et_DhNvM6RUpQwRpxGYJJirwOjHqTnhgxf_biinziTY=.4b01e158-54d5-417a-854f-b528c42fdedd@github.com>

On Thu, 22 Jun 2023 01:23:46 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The following bug was closed as "Cannot Reproduce":
> [8300709](https://bugs.openjdk.org/browse/JDK-8300709) nsk/jvmti/GetObjectMonitorUsage/objmonusage006 test asserts with virtual thread wrapper
> 
> I was not able to reproduce the assert in thousands mach5 runs on multiple debug builds.
> Also, the original sources were significantly changed, so it is not clear anymore in what context the assert was fired.
> The test is problem-listed in `ProblemList-Virtual.txt`.
> 
> This sub-task is to unproblem-list the test:
>    `vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage006/TestDescription.java`
>  
> If the original asset is reproduced again then the plan is to reopen the [8300709](https://bugs.openjdk.org/browse/JDK-8300709) and update it with the details needed for issue investigation.

Thank you for review, Chris.

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

PR Comment: https://git.openjdk.org/jdk/pull/14610#issuecomment-1602043814

From alanb at openjdk.org  Thu Jun 22 06:13:03 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 Jun 2023 06:13:03 GMT
Subject: RFR: 8306446: java/lang/management/ThreadMXBean/Locks.java
 transient failures [v3]
In-Reply-To: <zGKDknQD-6RpQfKA0E8VxfXFQKdM3FZLF82dmUuEYkc=.96b1ef20-0ad3-401b-8a08-b9775c1c9d62@github.com>
References: <yJLcr84uu61lDSWtJkQy1FptnlzMKpsWs1HEuO9idPQ=.938810ca-26ec-4ed1-83f6-f59a01a25d47@github.com>
 <sP587FPJLXH0m0QYOypszGvBG56TfaN2IY_XrdH6D9w=.42eb7e66-749b-4d9a-bde9-32f0c07a594c@github.com>
 <zGKDknQD-6RpQfKA0E8VxfXFQKdM3FZLF82dmUuEYkc=.96b1ef20-0ad3-401b-8a08-b9775c1c9d62@github.com>
Message-ID: <RIyN-P9Kgfh8u5qXuqkTe7nTlNFiJwGj007FaF7bB4I=.3783bb12-5091-4e63-a770-983b3a55dccd@github.com>

On Thu, 22 Jun 2023 01:43:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Can you elaborate on this please. I'm unclear how the test knows whether a thread may be holding any locks or not, but why is locking a VirtualThread instance a special case??

Carriers are reported as waiting, the string representation of the object that they are waiting on is the identity string of the virtual thread that is mounted.

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

PR Comment: https://git.openjdk.org/jdk/pull/14501#issuecomment-1602063138

From sspitsyn at openjdk.org  Thu Jun 22 06:43:10 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 22 Jun 2023 06:43:10 GMT
Subject: Integrated: 8309909: remove test nsk.jvmti test objmonusage006 from
 ProblemList-Virtual.txt
In-Reply-To: <H4jvWMeqkH1rAVrKUqCyMvg6QUVOWgniiZpPZojodeg=.a899ee8f-24b9-482b-b5fc-98a86a613ba6@github.com>
References: <H4jvWMeqkH1rAVrKUqCyMvg6QUVOWgniiZpPZojodeg=.a899ee8f-24b9-482b-b5fc-98a86a613ba6@github.com>
Message-ID: <mPqcCeAZBFa6EQWFCfOsG_x_EaqAPDjqVKx8s1PHSIA=.c2007948-a19e-457d-bcc8-e5b028b1da7d@github.com>

On Thu, 22 Jun 2023 01:23:46 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The following bug was closed as "Cannot Reproduce":
> [8300709](https://bugs.openjdk.org/browse/JDK-8300709) nsk/jvmti/GetObjectMonitorUsage/objmonusage006 test asserts with virtual thread wrapper
> 
> I was not able to reproduce the assert in thousands mach5 runs on multiple debug builds.
> Also, the original sources were significantly changed, so it is not clear anymore in what context the assert was fired.
> The test is problem-listed in `ProblemList-Virtual.txt`.
> 
> This sub-task is to unproblem-list the test:
>    `vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage006/TestDescription.java`
>  
> If the original asset is reproduced again then the plan is to reopen the [8300709](https://bugs.openjdk.org/browse/JDK-8300709) and update it with the details needed for issue investigation.

This pull request has now been integrated.

Changeset: 3bc475ee
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3bc475ee650a9564e957b9c8153944ec094ec6a2
Stats:     4 lines in 1 file changed: 0 ins; 4 del; 0 mod

8309909: remove test nsk.jvmti test objmonusage006 from ProblemList-Virtual.txt

Reviewed-by: cjplummer

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

PR: https://git.openjdk.org/jdk/pull/14610

From dqu at openjdk.org  Thu Jun 22 06:48:15 2023
From: dqu at openjdk.org (Daohan Qu)
Date: Thu, 22 Jun 2023 06:48:15 GMT
Subject: Integrated: 8242152: SA does not include StackMapTables when dumping
 .class files
In-Reply-To: <pBErA6eLKjV5Ydj7YKeOTkHW4VvuaylzXSdt2-QG2PE=.d4b64495-fbfd-467b-ad70-448e71fb3b1b@github.com>
References: <pBErA6eLKjV5Ydj7YKeOTkHW4VvuaylzXSdt2-QG2PE=.d4b64495-fbfd-467b-ad70-448e71fb3b1b@github.com>
Message-ID: <q4zXvwiVGqH_2rGkVwPCNoBX9A_Fsk8tmmXfQ6G5ZhQ=.833ec966-9c8f-4971-b4eb-ffb25dc90fc8@github.com>

On Tue, 20 Jun 2023 11:31:40 GMT, Daohan Qu <dqu at openjdk.org> wrote:

> This patch adds `StackMapTable` for the class files generated by `clhsdb`'s `buildreplayjars` command. This bug manifests itself during my diagnosing [JDK-8309751](https://bugs.openjdk.org/browse/JDK-8309751) and needs to be fixed first.
> 
> I have run jtreg test `tier1-3` of release build on x86 linux finding only one failure in `tier2` caused by [JDK-8309214](https://bugs.openjdk.org/browse/JDK-8309214). `jtreg:test/hotspot/jtreg/serviceability` and `jtreg:test/jdk/sun/tools/` also passed.

This pull request has now been integrated.

Changeset: 8e047029
Author:    Daohan Qu <dqu at openjdk.org>
Committer: Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8e047029e811a9e5758d564249ee794f584c9dc2
Stats:     60 lines in 4 files changed: 60 ins; 0 del; 0 mod

8242152: SA does not include StackMapTables when dumping .class files

Reviewed-by: cjplummer, sspitsyn

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

PR: https://git.openjdk.org/jdk/pull/14556

From sspitsyn at openjdk.org  Thu Jun 22 06:51:02 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 22 Jun 2023 06:51:02 GMT
Subject: RFR: 8294316: SA core file support is broken on macosx-x64
 starting with macOS 12.x
In-Reply-To: <0wPtkRqjB3Nh6LiABARFcqq6UqcCsTNbF1ok1iG0Efw=.af55940f-5b2d-4cfb-b233-066a419bae48@github.com>
References: <0wPtkRqjB3Nh6LiABARFcqq6UqcCsTNbF1ok1iG0Efw=.af55940f-5b2d-4cfb-b233-066a419bae48@github.com>
Message-ID: <SILZYwGzI6K7Dx1DlJiBl3qv9wllswPwd3ITmFFdU6Y=.e22be2b6-15f5-4eaa-bd01-c7c2618e0e25@github.com>

On Tue, 20 Jun 2023 18:05:09 GMT, Tom Rodriguez <never at openjdk.org> wrote:

> This is a minor fix to core file reading on macos x.  I can confirm that after this fix I can run the problem listed SA core file tests on Ventura.

Looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14569#pullrequestreview-1492479235

From dqu at openjdk.org  Thu Jun 22 07:27:12 2023
From: dqu at openjdk.org (Daohan Qu)
Date: Thu, 22 Jun 2023 07:27:12 GMT
Subject: RFR: 8242152: SA does not include StackMapTables when dumping
 .class files [v3]
In-Reply-To: <VnJD6sy-w0jZDFFK23NEl7hw82JzsLtazQTD4-zScmQ=.90b285d8-51b9-4bbb-920f-160eaf273ea4@github.com>
References: <pBErA6eLKjV5Ydj7YKeOTkHW4VvuaylzXSdt2-QG2PE=.d4b64495-fbfd-467b-ad70-448e71fb3b1b@github.com>
 <VnJD6sy-w0jZDFFK23NEl7hw82JzsLtazQTD4-zScmQ=.90b285d8-51b9-4bbb-920f-160eaf273ea4@github.com>
Message-ID: <jLhEf6sXCQulO6W_vrNMq3ZXkpsFhCHNX4yCrHW0ySQ=.12e34f36-2e34-4979-9e89-0f5414d78fad@github.com>

On Thu, 22 Jun 2023 04:00:14 GMT, Daohan Qu <dqu at openjdk.org> wrote:

>> This patch adds `StackMapTable` for the class files generated by `clhsdb`'s `buildreplayjars` command. This bug manifests itself during my diagnosing [JDK-8309751](https://bugs.openjdk.org/browse/JDK-8309751) and needs to be fixed first.
>> 
>> I have run jtreg test `tier1-3` of release build on x86 linux finding only one failure in `tier2` caused by [JDK-8309214](https://bugs.openjdk.org/browse/JDK-8309214). `jtreg:test/hotspot/jtreg/serviceability` and `jtreg:test/jdk/sun/tools/` also passed.
>
> Daohan Qu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a simple check

On no. CI shows that my added test statement passes on Linux but fails on Windows. This is sort of wierd. Shouldn't class file format be platform agnostic? I'd take a look at it.

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

PR Comment: https://git.openjdk.org/jdk/pull/14556#issuecomment-1602143208

From dholmes at openjdk.org  Thu Jun 22 07:38:13 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 22 Jun 2023 07:38:13 GMT
Subject: RFR: 8242152: SA does not include StackMapTables when dumping
 .class files [v3]
In-Reply-To: <VnJD6sy-w0jZDFFK23NEl7hw82JzsLtazQTD4-zScmQ=.90b285d8-51b9-4bbb-920f-160eaf273ea4@github.com>
References: <pBErA6eLKjV5Ydj7YKeOTkHW4VvuaylzXSdt2-QG2PE=.d4b64495-fbfd-467b-ad70-448e71fb3b1b@github.com>
 <VnJD6sy-w0jZDFFK23NEl7hw82JzsLtazQTD4-zScmQ=.90b285d8-51b9-4bbb-920f-160eaf273ea4@github.com>
Message-ID: <Ueq4I7PDFoV_lXSNuINgXBfZu-yJqHArMMHlca8WKFM=.2eabf486-8398-46c5-8e30-62409f371d0c@github.com>

On Thu, 22 Jun 2023 04:00:14 GMT, Daohan Qu <dqu at openjdk.org> wrote:

>> This patch adds `StackMapTable` for the class files generated by `clhsdb`'s `buildreplayjars` command. This bug manifests itself during my diagnosing [JDK-8309751](https://bugs.openjdk.org/browse/JDK-8309751) and needs to be fixed first.
>> 
>> I have run jtreg test `tier1-3` of release build on x86 linux finding only one failure in `tier2` caused by [JDK-8309214](https://bugs.openjdk.org/browse/JDK-8309214). `jtreg:test/hotspot/jtreg/serviceability` and `jtreg:test/jdk/sun/tools/` also passed.
>
> Daohan Qu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a simple check

We see a tier1 failure on Linux-x64-debug running `serviceability/sa/ClhsdbDumpclass.java`

ava.lang.RuntimeException: Test ERROR java.lang.RuntimeException: 'StackMapTable:' missing from stdout/stderr
	at ClhsdbDumpclass.main(ClhsdbDumpclass.java:97)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
	at java.base/java.lang.Thread.run(Thread.java:1570)
Caused by: java.lang.RuntimeException: 'StackMapTable:' missing from stdout/stderr
	at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:221)
	at ClhsdbDumpclass.main(ClhsdbDumpclass.java:92)
	... 4 more

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

PR Comment: https://git.openjdk.org/jdk/pull/14556#issuecomment-1602156383

From dholmes at openjdk.org  Thu Jun 22 07:45:13 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 22 Jun 2023 07:45:13 GMT
Subject: RFR: 8242152: SA does not include StackMapTables when dumping
 .class files [v3]
In-Reply-To: <VnJD6sy-w0jZDFFK23NEl7hw82JzsLtazQTD4-zScmQ=.90b285d8-51b9-4bbb-920f-160eaf273ea4@github.com>
References: <pBErA6eLKjV5Ydj7YKeOTkHW4VvuaylzXSdt2-QG2PE=.d4b64495-fbfd-467b-ad70-448e71fb3b1b@github.com>
 <VnJD6sy-w0jZDFFK23NEl7hw82JzsLtazQTD4-zScmQ=.90b285d8-51b9-4bbb-920f-160eaf273ea4@github.com>
Message-ID: <lfJHF82cliEMLLwokyAcPVTVxjCzOIa-bFwvNKQ3hPM=.4c38b36a-71bd-42e4-b41c-7d5c0310c06a@github.com>

On Thu, 22 Jun 2023 04:00:14 GMT, Daohan Qu <dqu at openjdk.org> wrote:

>> This patch adds `StackMapTable` for the class files generated by `clhsdb`'s `buildreplayjars` command. This bug manifests itself during my diagnosing [JDK-8309751](https://bugs.openjdk.org/browse/JDK-8309751) and needs to be fixed first.
>> 
>> I have run jtreg test `tier1-3` of release build on x86 linux finding only one failure in `tier2` caused by [JDK-8309214](https://bugs.openjdk.org/browse/JDK-8309214). `jtreg:test/hotspot/jtreg/serviceability` and `jtreg:test/jdk/sun/tools/` also passed.
>
> Daohan Qu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a simple check

What output is the test looking for i.e why is supposed to be writing it? If it is the `if (DEBUG) debugMessage(...)` calls they are not enabled.

I've filed https://bugs.openjdk.org/browse/JDK-8310618

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

PR Comment: https://git.openjdk.org/jdk/pull/14556#issuecomment-1602161425
PR Comment: https://git.openjdk.org/jdk/pull/14556#issuecomment-1602165383

From dqu at openjdk.org  Thu Jun 22 07:45:14 2023
From: dqu at openjdk.org (Daohan Qu)
Date: Thu, 22 Jun 2023 07:45:14 GMT
Subject: RFR: 8242152: SA does not include StackMapTables when dumping
 .class files [v3]
In-Reply-To: <VnJD6sy-w0jZDFFK23NEl7hw82JzsLtazQTD4-zScmQ=.90b285d8-51b9-4bbb-920f-160eaf273ea4@github.com>
References: <pBErA6eLKjV5Ydj7YKeOTkHW4VvuaylzXSdt2-QG2PE=.d4b64495-fbfd-467b-ad70-448e71fb3b1b@github.com>
 <VnJD6sy-w0jZDFFK23NEl7hw82JzsLtazQTD4-zScmQ=.90b285d8-51b9-4bbb-920f-160eaf273ea4@github.com>
Message-ID: <_8ExZqhaP1JIAizJ1OgWQnMBnHARLM4INCKF8e965Vw=.7fa3d707-d2c2-4d76-9508-18184e7852f7@github.com>

On Thu, 22 Jun 2023 04:00:14 GMT, Daohan Qu <dqu at openjdk.org> wrote:

>> This patch adds `StackMapTable` for the class files generated by `clhsdb`'s `buildreplayjars` command. This bug manifests itself during my diagnosing [JDK-8309751](https://bugs.openjdk.org/browse/JDK-8309751) and needs to be fixed first.
>> 
>> I have run jtreg test `tier1-3` of release build on x86 linux finding only one failure in `tier2` caused by [JDK-8309214](https://bugs.openjdk.org/browse/JDK-8309214). `jtreg:test/hotspot/jtreg/serviceability` and `jtreg:test/jdk/sun/tools/` also passed.
>
> Daohan Qu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a simple check

My fault. Thanks for your reporting, David. I will look into this immediately. I didn't find that maybe because I run tests on Linux using release build.

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

PR Comment: https://git.openjdk.org/jdk/pull/14556#issuecomment-1602163080

From dqu at openjdk.org  Thu Jun 22 07:50:18 2023
From: dqu at openjdk.org (Daohan Qu)
Date: Thu, 22 Jun 2023 07:50:18 GMT
Subject: RFR: 8242152: SA does not include StackMapTables when dumping
 .class files [v3]
In-Reply-To: <lfJHF82cliEMLLwokyAcPVTVxjCzOIa-bFwvNKQ3hPM=.4c38b36a-71bd-42e4-b41c-7d5c0310c06a@github.com>
References: <pBErA6eLKjV5Ydj7YKeOTkHW4VvuaylzXSdt2-QG2PE=.d4b64495-fbfd-467b-ad70-448e71fb3b1b@github.com>
 <VnJD6sy-w0jZDFFK23NEl7hw82JzsLtazQTD4-zScmQ=.90b285d8-51b9-4bbb-920f-160eaf273ea4@github.com>
 <lfJHF82cliEMLLwokyAcPVTVxjCzOIa-bFwvNKQ3hPM=.4c38b36a-71bd-42e4-b41c-7d5c0310c06a@github.com>
Message-ID: <yd3jiehZlKnsHpDhbWTVFP1cZO-oMtphPWS35DHOsPw=.658b0a3b-5deb-45b3-8890-05f0e5467763@github.com>

On Thu, 22 Jun 2023 07:38:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

> What output is the test looking for i.e why is supposed to be writing it? If it is the?if (DEBUG) debugMessage(...)?calls they are not enabled.

It is looking for `StackMapTable` info in the javap output.

> I've filed?https://bugs.openjdk.org/browse/JDK-8310618

Thanks, David! Sorry for any inconvenience casued by that.

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

PR Comment: https://git.openjdk.org/jdk/pull/14556#issuecomment-1602169594
PR Comment: https://git.openjdk.org/jdk/pull/14556#issuecomment-1602171361

From mbaesken at openjdk.org  Thu Jun 22 08:12:04 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 22 Jun 2023 08:12:04 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work
In-Reply-To: <P0OBubziQAeWtqlOFA7qMWjTCxZtkPgDNqD1mt2OSWk=.85ab4ce6-dc69-43c4-b32f-8e0b6b850b2b@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
 <P0OBubziQAeWtqlOFA7qMWjTCxZtkPgDNqD1mt2OSWk=.85ab4ce6-dc69-43c4-b32f-8e0b6b850b2b@github.com>
Message-ID: <4pvbSkswpD7S3YrIJDJV-DXs4EiXg_Ar7eC1bTTVx8w=.6a1265d8-d5e6-437d-87dd-aa0afbda4495@github.com>

On Wed, 21 Jun 2023 15:25:15 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
>> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
>> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
>> But without the entitlement, a core is not generated.
>
> test/lib/jdk/test/lib/Platform.java line 280:
> 
>> 278:         String line;
>> 279:         while ((line = is.readLine()) != null) {
>> 280:             System.out.println("STDOUT: " + line);
> 
> This output is for every line seems too much. Maybe just print the lines where you find "Info.plist=not bound" or "Info.plist entries="?

I found the output useful when analyzing the issue (and it is just a few lines).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14562#discussion_r1238163572

From aboldtch at openjdk.org  Thu Jun 22 08:47:11 2023
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 22 Jun 2023 08:47:11 GMT
Subject: [jdk21] Integrated: 8310187: Improve Generational ZGC jtreg testing
In-Reply-To: <cxzJD8H_hBo9D066bXYhT9TKHj2-83IRtHw6hbD0h3s=.09fc98f5-5fd1-42f5-b1c2-9b198c0956fc@github.com>
References: <cxzJD8H_hBo9D066bXYhT9TKHj2-83IRtHw6hbD0h3s=.09fc98f5-5fd1-42f5-b1c2-9b198c0956fc@github.com>
Message-ID: <-l-PUtkHpuka6haLkl2dJ7vfY0xRZuphvpoT8tGv7ZA=.d3088503-3528-4190-9579-893355eb91af@github.com>

On Tue, 20 Jun 2023 11:17:40 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [a0595761](https://github.com/openjdk/jdk/commit/a0595761ef35c4eec8cb84326a869b9473cd5bba) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Axel Boldt-Christmas on 20 Jun 2023 and was reviewed by Stefan Karlsson, Erik ?sterlund and Thomas Stuefe.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 6317249b
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/6317249b50e039474f67c15507134bfc65a0fa79
Stats:     619 lines in 70 files changed: 447 ins; 5 del; 167 mod

8310187: Improve Generational ZGC jtreg testing

Reviewed-by: eosterlund
Backport-of: a0595761ef35c4eec8cb84326a869b9473cd5bba

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

PR: https://git.openjdk.org/jdk21/pull/37

From kevinw at openjdk.org  Thu Jun 22 09:04:12 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 22 Jun 2023 09:04:12 GMT
Subject: RFR: 8242152: SA does not include StackMapTables when dumping
 .class files [v3]
In-Reply-To: <VnJD6sy-w0jZDFFK23NEl7hw82JzsLtazQTD4-zScmQ=.90b285d8-51b9-4bbb-920f-160eaf273ea4@github.com>
References: <pBErA6eLKjV5Ydj7YKeOTkHW4VvuaylzXSdt2-QG2PE=.d4b64495-fbfd-467b-ad70-448e71fb3b1b@github.com>
 <VnJD6sy-w0jZDFFK23NEl7hw82JzsLtazQTD4-zScmQ=.90b285d8-51b9-4bbb-920f-160eaf273ea4@github.com>
Message-ID: <J1lVzx-VdWTJmqx_lqNhWnFJlgXfSjwuli3e3goB_k4=.51045ab2-b911-4a2f-83e4-f2dd5769eee0@github.com>

On Thu, 22 Jun 2023 04:00:14 GMT, Daohan Qu <dqu at openjdk.org> wrote:

>> This patch adds `StackMapTable` for the class files generated by `clhsdb`'s `buildreplayjars` command. This bug manifests itself during my diagnosing [JDK-8309751](https://bugs.openjdk.org/browse/JDK-8309751) and needs to be fixed first.
>> 
>> I have run jtreg test `tier1-3` of release build on x86 linux finding only one failure in `tier2` caused by [JDK-8309214](https://bugs.openjdk.org/browse/JDK-8309214). `jtreg:test/hotspot/jtreg/serviceability` and `jtreg:test/jdk/sun/tools/` also passed.
>
> Daohan Qu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a simple check

I see the failure too.  javap needs "-v" to show the StackMap info, I see that on linux release and debug builds.

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

PR Comment: https://git.openjdk.org/jdk/pull/14556#issuecomment-1602272184

From dqu at openjdk.org  Thu Jun 22 09:04:13 2023
From: dqu at openjdk.org (Daohan Qu)
Date: Thu, 22 Jun 2023 09:04:13 GMT
Subject: RFR: 8242152: SA does not include StackMapTables when dumping
 .class files [v3]
In-Reply-To: <J1lVzx-VdWTJmqx_lqNhWnFJlgXfSjwuli3e3goB_k4=.51045ab2-b911-4a2f-83e4-f2dd5769eee0@github.com>
References: <pBErA6eLKjV5Ydj7YKeOTkHW4VvuaylzXSdt2-QG2PE=.d4b64495-fbfd-467b-ad70-448e71fb3b1b@github.com>
 <VnJD6sy-w0jZDFFK23NEl7hw82JzsLtazQTD4-zScmQ=.90b285d8-51b9-4bbb-920f-160eaf273ea4@github.com>
 <J1lVzx-VdWTJmqx_lqNhWnFJlgXfSjwuli3e3goB_k4=.51045ab2-b911-4a2f-83e4-f2dd5769eee0@github.com>
Message-ID: <P4nfPYrQlNt3jkxDmTyPLTDseENc6T0uE6ap7kdLnok=.06de810f-60b9-44df-8b10-fe1230071bf6@github.com>

On Thu, 22 Jun 2023 08:59:42 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> I see the failure too. javap needs "-v" to show the StackMap info, I see that on linux release and debug builds.

Exactly! @kevinjwalls. And a situation similar to [this one](https://github.com/openjdk/jdk/pull/3004#issuecomment-800679752) happen again. Thanks for your investigation. I would fix it ASAP.

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

PR Comment: https://git.openjdk.org/jdk/pull/14556#issuecomment-1602275012

From asemenov at openjdk.org  Thu Jun 22 09:13:21 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 22 Jun 2023 09:13:21 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v6]
In-Reply-To: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
Message-ID: <MLeeOEZNEOO96LlsTWqsL7v2VU3Xk8gLWxE6ZA8HEl8=.90a7959a-6126-40f3-a67b-738a5eb50efd@github.com>

> 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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14033/files
  - new: https://git.openjdk.org/jdk/pull/14033/files/101bf062..842d33d8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=04-05

  Stats: 26 lines in 5 files changed: 11 ins; 11 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14033.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14033/head:pull/14033

PR: https://git.openjdk.org/jdk/pull/14033

From asemenov at openjdk.org  Thu Jun 22 09:13:24 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 22 Jun 2023 09:13:24 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v5]
In-Reply-To: <e03s86poTfLMgZxAIbbZrWI80VKIVgor9KM-f9egCU0=.2f374c5d-b95b-4262-a452-7b3dd96643bc@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <uTI-0-FTTOiVf6_6psxvUks06Xj57078fd8yzoUkb5E=.d0f3deb0-8199-46fc-b259-18d41ad3cbbb@github.com>
 <e03s86poTfLMgZxAIbbZrWI80VKIVgor9KM-f9egCU0=.2f374c5d-b95b-4262-a452-7b3dd96643bc@github.com>
Message-ID: <1uzHyJeBll4YnB4uuKYWFX8e7z66iWHoYK4Ksu8T3Ic=.c2a86584-ea77-48f9-8306-368edb33d0af@github.com>

On Wed, 21 Jun 2023 07:35:16 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Artem Semenov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - update
>>  - update
>>  - update
>>  - update
>>  - 8308286 Fix clang warnings in linux code
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 235:
> 
>> 233:         DISABLED_WARNINGS_gcc := int-to-pointer-cast, \
>> 234:         DISABLED_WARNINGS_gcc_awt_Taskbar.c := parentheses, \
>> 235:         DISABLED_WARNINGS_clang_awt_Taskbar.c := parentheses, \
> 
> please group the disabled warnings by compiler (gcc, then clang, then clang_aix)

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1238236415

From dqu at openjdk.org  Thu Jun 22 09:25:37 2023
From: dqu at openjdk.org (Daohan Qu)
Date: Thu, 22 Jun 2023 09:25:37 GMT
Subject: RFR: 8310618: Test serviceability/sa/ClhsdbDumpclass.java fails after
 8242152: 'StackMapTable:' missing from stdout/stderr
Message-ID: <dBDHdSeZ0XJYik39OxhkIqM1s6xX5luh9ku7nTtBBTw=.71e1b047-2737-4b94-a723-276dac089ac7@github.com>

This patch should fix [JDK-8310618](https://bugs.openjdk.org/browse/JDK-8310618). It attempts to correct my errors in fixing [JDK-8242152](https://bugs.openjdk.org/browse/JDK-8242152).

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

Commit messages:
 - Let javap print additional info for checking

Changes: https://git.openjdk.org/jdk/pull/14612/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14612&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310618
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14612.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14612/head:pull/14612

PR: https://git.openjdk.org/jdk/pull/14612

From mbaesken at openjdk.org  Thu Jun 22 09:26:06 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 22 Jun 2023 09:26:06 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar
In-Reply-To: <RhyKQERReuok9CVTDMV57hGRtnfTtUnKMEWfVLKQepQ=.afa0d7fb-99a5-486d-83e1-db7cbfbf7ccf@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
 <RhyKQERReuok9CVTDMV57hGRtnfTtUnKMEWfVLKQepQ=.afa0d7fb-99a5-486d-83e1-db7cbfbf7ccf@github.com>
Message-ID: <ggJTRFLg4cRBkeXkY_gGOQPI8dBTg_PTbto4yhl0Rp8=.6335d5a3-9653-48d6-886b-61851ac31014@github.com>

On Wed, 21 Jun 2023 21:46:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java line 196:
> 
>> 194: 
>> 195:     /**
>> 196:      * Set whether or not to use ct.sym as an alternate
> 
> As an alternate to what? This needs something else.

should "to the image modules files"  be used instead ?

> test/langtools/tools/javap/4798312/JavapShouldLoadClassesFromRTJarTest.java line 1:
> 
>> 1: /*
> 
> The name of this test includes RTJar. It needs to be changed too I think. Does this test actually still test something?

It seems to start a javap. So I think it tests something, how important this is and what other tests might cover similar stuff, I do not know unfortunately .

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1238252196
PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1238254149

From kevinw at openjdk.org  Thu Jun 22 09:40:02 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 22 Jun 2023 09:40:02 GMT
Subject: RFR: 8310618: Test serviceability/sa/ClhsdbDumpclass.java fails
 after 8242152: 'StackMapTable:' missing from stdout/stderr
In-Reply-To: <dBDHdSeZ0XJYik39OxhkIqM1s6xX5luh9ku7nTtBBTw=.71e1b047-2737-4b94-a723-276dac089ac7@github.com>
References: <dBDHdSeZ0XJYik39OxhkIqM1s6xX5luh9ku7nTtBBTw=.71e1b047-2737-4b94-a723-276dac089ac7@github.com>
Message-ID: <xSgsebTZb-KAhcBFEphHcINr0SAShA0hcPrAkaThsEI=.51575568-2772-4445-b318-e339c6b3b694@github.com>

On Thu, 22 Jun 2023 09:17:46 GMT, Daohan Qu <dqu at openjdk.org> wrote:

> This patch should fix [JDK-8310618](https://bugs.openjdk.org/browse/JDK-8310618). It attempts to correct my errors in fixing [JDK-8242152](https://bugs.openjdk.org/browse/JDK-8242152).

Yes, looks good. 8-)

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

Marked as reviewed by kevinw (Committer).

PR Review: https://git.openjdk.org/jdk/pull/14612#pullrequestreview-1492792655

From dqu at openjdk.org  Thu Jun 22 09:43:03 2023
From: dqu at openjdk.org (Daohan Qu)
Date: Thu, 22 Jun 2023 09:43:03 GMT
Subject: RFR: 8310618: Test serviceability/sa/ClhsdbDumpclass.java fails
 after 8242152: 'StackMapTable:' missing from stdout/stderr
In-Reply-To: <xSgsebTZb-KAhcBFEphHcINr0SAShA0hcPrAkaThsEI=.51575568-2772-4445-b318-e339c6b3b694@github.com>
References: <dBDHdSeZ0XJYik39OxhkIqM1s6xX5luh9ku7nTtBBTw=.71e1b047-2737-4b94-a723-276dac089ac7@github.com>
 <xSgsebTZb-KAhcBFEphHcINr0SAShA0hcPrAkaThsEI=.51575568-2772-4445-b318-e339c6b3b694@github.com>
Message-ID: <CoQVRq3WCFEBfB1__klurY-ULuhT8a1V2nJhr_ghy58=.cd7cd090-30d4-4773-8995-3c67c8593512@github.com>

On Thu, 22 Jun 2023 09:37:40 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> This patch should fix [JDK-8310618](https://bugs.openjdk.org/browse/JDK-8310618). It attempts to correct my errors in fixing [JDK-8242152](https://bugs.openjdk.org/browse/JDK-8242152).
>
> Yes, looks good. 8-)

Thanks for your reviews @kevinjwalls ! But this time let's wait until all the CI tests pass :P

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

PR Comment: https://git.openjdk.org/jdk/pull/14612#issuecomment-1602328554

From mbaesken at openjdk.org  Thu Jun 22 09:53:29 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 22 Jun 2023 09:53:29 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work [v2]
In-Reply-To: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
Message-ID: <69LRKDeH8L61mW040KBn5pD_hWg09rVHvI4e1SuMl5g=.b127ba99-3eda-4542-b9ba-b0eaa75941e4@github.com>

> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
> But without the entitlement, a core is not generated.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Some adjustments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14562/files
  - new: https://git.openjdk.org/jdk/pull/14562/files/0d8c68c2..1b604db9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14562&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14562&range=00-01

  Stats: 37 lines in 5 files changed: 17 ins; 10 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/14562.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14562/head:pull/14562

PR: https://git.openjdk.org/jdk/pull/14562

From mbaesken at openjdk.org  Thu Jun 22 09:53:29 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 22 Jun 2023 09:53:29 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work
In-Reply-To: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
Message-ID: <b_loscpG1LcPQ6jUXpSinaEEm1D4WwYeh6Nk8EaskHw=.d18d1729-dd6e-449a-b45f-a99fe53cb89d@github.com>

On Tue, 20 Jun 2023 13:23:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
> But without the entitlement, a core is not generated.

I adjusted COPYRIGHT info, adjusted TestMutuallyExclusivePlatformPredicates.java .
Also simplified the coding in Platform.java a bit.

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

PR Comment: https://git.openjdk.org/jdk/pull/14562#issuecomment-1602340023

From mbaesken at openjdk.org  Thu Jun 22 09:53:29 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 22 Jun 2023 09:53:29 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work [v2]
In-Reply-To: <2hTz6Ylp5KA89yQymiGug9j251kWEWeEYKL01an3gqM=.b270bd6f-0c69-4bec-8a6b-b423dc6d70d9@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
 <2hTz6Ylp5KA89yQymiGug9j251kWEWeEYKL01an3gqM=.b270bd6f-0c69-4bec-8a6b-b423dc6d70d9@github.com>
Message-ID: <9BGK9J99tjP0UEZdoJU5BHJwadhXskzU2eK6HZ_-z4w=.2b048728-6ba1-4acf-8cdf-aee0c3adffdd@github.com>

On Wed, 21 Jun 2023 19:32:23 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Some adjustments
>
> test/lib/jdk/test/lib/util/CoreUtils.java line 131:
> 
>> 129:             return coreFileLocation; // success!
>> 130:         } else {
>> 131:             System.out.println("Core file not found, try to find a reason for this");
> 
> Suggestion:
> 
>             System.out.println("Core file not found. Trying to find a reason why...");

I changed the message.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14562#discussion_r1238282996

From djelinski at openjdk.org  Thu Jun 22 10:02:09 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 22 Jun 2023 10:02:09 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v6]
In-Reply-To: <MLeeOEZNEOO96LlsTWqsL7v2VU3Xk8gLWxE6ZA8HEl8=.90a7959a-6126-40f3-a67b-738a5eb50efd@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <MLeeOEZNEOO96LlsTWqsL7v2VU3Xk8gLWxE6ZA8HEl8=.90a7959a-6126-40f3-a67b-738a5eb50efd@github.com>
Message-ID: <xyC94f3rya2zlmfsqw0_SWQgYwdzfjd0TWcVHvye0as=.a02de106-6ca2-4ef8-bca4-019854019348@github.com>

On Thu, 22 Jun 2023 09:13:21 GMT, Artem Semenov <asemenov at openjdk.org> 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

make/modules/java.desktop/lib/Awt2dLibraries.gmk line 241:

> 239:                 DISABLED_WARNINGS_gcc_OGLPaints.c := format-nonliteral, \
> 240:                 DISABLED_WARNINGS_gcc_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \
> 241:                 DISABLED_WARNINGS_gcc_X11SurfaceData.c := implicit-fallthrough pointer-to-int-cast, \

Suggestion:

        DISABLED_WARNINGS_gcc_GLXSurfaceData.c := unused-function, \
        DISABLED_WARNINGS_gcc_gtk2_interface.c := parentheses type-limits, \
        DISABLED_WARNINGS_gcc_gtk3_interface.c := parentheses type-limits unused-function, \
        DISABLED_WARNINGS_gcc_OGLBufImgOps.c := format-nonliteral, \
        DISABLED_WARNINGS_gcc_OGLPaints.c := format-nonliteral, \
        DISABLED_WARNINGS_gcc_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \
        DISABLED_WARNINGS_gcc_X11SurfaceData.c := implicit-fallthrough pointer-to-int-cast, \

make/modules/java.desktop/lib/Awt2dLibraries.gmk line 260:

> 258:         DISABLED_WARNINGS_clang_aix_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \
> 259:         DISABLED_WARNINGS_clang_aix_awt_InputMethod.c := sign-compare, \
> 260:         DISABLED_WARNINGS_clang_screencast_pipewire.c := format-nonliteral, \

move this one closer to the other clang (non-aix) suppressions

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1238296391
PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1238297332

From clanger at openjdk.org  Thu Jun 22 10:57:08 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 22 Jun 2023 10:57:08 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work [v2]
In-Reply-To: <69LRKDeH8L61mW040KBn5pD_hWg09rVHvI4e1SuMl5g=.b127ba99-3eda-4542-b9ba-b0eaa75941e4@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
 <69LRKDeH8L61mW040KBn5pD_hWg09rVHvI4e1SuMl5g=.b127ba99-3eda-4542-b9ba-b0eaa75941e4@github.com>
Message-ID: <GGGG9CKG556EUDfDUmDUMomSxvRB81VyGrt0sbXRchM=.59c82f26-0d1c-43a2-ae8c-d28482b793da@github.com>

On Thu, 22 Jun 2023 09:53:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
>> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
>> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
>> But without the entitlement, a core is not generated.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Some adjustments

Looks a bit better. But I think instead of adding a Utils.javaPath() method, you can do all this path handling in Platform.launchCodesignOnJavaBinary(). Then even more code would be shared.

test/lib/jdk/test/lib/Platform.java line 263:

> 261:     }
> 262: 
> 263:     private static codesignProcess launchCodesignOnJavaBinary(String javaFileName) {

That can't work... should be `private static Process` ?

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

Changes requested by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14562#pullrequestreview-1492927024
PR Review Comment: https://git.openjdk.org/jdk/pull/14562#discussion_r1238354879

From kevinw at openjdk.org  Thu Jun 22 11:11:06 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 22 Jun 2023 11:11:06 GMT
Subject: RFR: 8310628: GcInfoBuilder.c missing JNI Exception checks
Message-ID: <87ZNvqRyVQt6jH_m0k0e6rp3ZgtEqmsHucDrNz27DSA=.985f5cc9-8938-4f70-89fa-35c93cb6606f@github.com>

JNI calls were identified, where we do not check for a pending Exception afterwards.

(JDK-8162530 cleaned up up some of these kind of issues some years back, but more were found.)

I tested a code change to manually create an Exception before some of the new ExceptionCheck calls, and this is correctly recognised, we see an Exception thrown by the native getLastGcInfo0, e.g. 

java.lang.NullPointerException: XXX Test Exception
        at jdk.management/com.sun.management.internal.GcInfoBuilder.getLastGcInfo0(Native Method)
        at jdk.management/com.sun.management.internal.GcInfoBuilder.getLastGcInfo(GcInfoBuilder.java:77)
        at jdk.management/com.sun.management.internal.GarbageCollectorExtImpl.getLastGcInfo(GarbageCollectorExtImpl.java:69)
        at LastGCInfo.main(LastGCInfo.java:53)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
        at java.base/java.lang.reflect.Method.invoke(Method.java:580)
        at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
        at java.base/java.lang.Thread.run(Thread.java:1570)

Tested with all of test/jdk/com/sun/management including test/jdk/com/sun/management/GarbageCollectorMXBean/LastGCInfo.java

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

Commit messages:
 - 8310628: GcInfoBuilder.c missing JNI Exception checks

Changes: https://git.openjdk.org/jdk/pull/14613/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14613&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310628
  Stats: 29 lines in 1 file changed: 20 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/14613.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14613/head:pull/14613

PR: https://git.openjdk.org/jdk/pull/14613

From kevinw at openjdk.org  Thu Jun 22 11:30:04 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 22 Jun 2023 11:30:04 GMT
Subject: RFR: 8306446: java/lang/management/ThreadMXBean/Locks.java
 transient failures [v3]
In-Reply-To: <sP587FPJLXH0m0QYOypszGvBG56TfaN2IY_XrdH6D9w=.42eb7e66-749b-4d9a-bde9-32f0c07a594c@github.com>
References: <yJLcr84uu61lDSWtJkQy1FptnlzMKpsWs1HEuO9idPQ=.938810ca-26ec-4ed1-83f6-f59a01a25d47@github.com>
 <sP587FPJLXH0m0QYOypszGvBG56TfaN2IY_XrdH6D9w=.42eb7e66-749b-4d9a-bde9-32f0c07a594c@github.com>
Message-ID: <bgY05q_sULvXbKocYtn6l-dO-_BcDUqIuTfTF9bWcZU=.69092515-88db-4091-ab8f-c6ea12aa2bf3@github.com>

On Wed, 21 Jun 2023 16:56:08 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> This test iterates an array of ThreadInfos in a few places (e.g. in the method doCheck()), and needs to tolerate and ignore nulls, in case a thread finishes and the test hits an NPE.
>> 
>> There are other calls like "TM.getThreadInfo(tid).getLockName()" which might often be risky, but if the threads are blocked as they are here, they can't be terminating, so this usage is safe.
>> 
>> 
>> The test has additional problems when started in a virtual thread.  ThreadMXBean.getThreadInfo() methods only return a ThreadInfo for platform threads.  The test needs to avoid some checks if mainThread is virtual.
>> 
>> In assertNoLock, it needs to not object to a thread holding a lock on a VirtualThread object is not relevant.
>> Also the loop in doChecks which follows a chain of locks... This needs to recognise that ForkJoinPool thead is not worth pursuing.  It's not one of the very narrow set of threads this test cares about.
>> 
>> Despite these exclusions, the test does some reasonable verification work when MainThread is virtual.  This test historically cam in with a general "JVM monitoring and management API" change, it is not testing a particular fix.
>> 
>> 
>> There's a failure condition in doCheck() which will not make the test fail: if it logs "TEST FAILED" in its final for loop, there is no failure.  Make the loop count the failures, and throw if there are any.
>> 
>> Also, while looking into this...  The variable names in some methods are confusing. In checkBlockedObject(), let's use "threadName" rather than "result" if we are finding a thread name, and let's not reuse the same result variable for a lockName later in the method.
>> 
>> The logs from this test are hard to read and verify, I find it better if the lock objects OBJB and OBJC are of classes other than Object, so you get to read, e.g.:
>> LockAThread blocked on Locks$ObjectB at 4691fdfd
>> (ObjectB, not just Object).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment update

Thanks Alan, yes-
All the TEST really knows is the couple of threads it creates, and the lock objects it creates.  When it says "assert no lock held", it means to assert that none of the locks that it created and cares about are held.

When MainThread is Virtual, as started by jtreg, the test asserts that no locks it cares about are held by MainThread.  When there is an additional locked object (a VirtualThread), that surprises the test. Hence the filter on getLockName() in assertNoLock.

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

PR Comment: https://git.openjdk.org/jdk/pull/14501#issuecomment-1602473395

From mbaesken at openjdk.org  Thu Jun 22 11:51:15 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 22 Jun 2023 11:51:15 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work [v3]
In-Reply-To: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
Message-ID: <LdyQw-4zZwjHIW1MC9q43Nekj30shwvyJBaNbPsLg54=.bb966145-68be-4e46-89a5-12c1f0b9048e@github.com>

> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
> But without the entitlement, a core is not generated.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  move javaPath into caller

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14562/files
  - new: https://git.openjdk.org/jdk/pull/14562/files/1b604db9..619b3578

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14562&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14562&range=01-02

  Stats: 32 lines in 2 files changed: 6 ins; 23 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14562.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14562/head:pull/14562

PR: https://git.openjdk.org/jdk/pull/14562

From mbaesken at openjdk.org  Thu Jun 22 11:51:16 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 22 Jun 2023 11:51:16 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work [v2]
In-Reply-To: <69LRKDeH8L61mW040KBn5pD_hWg09rVHvI4e1SuMl5g=.b127ba99-3eda-4542-b9ba-b0eaa75941e4@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
 <69LRKDeH8L61mW040KBn5pD_hWg09rVHvI4e1SuMl5g=.b127ba99-3eda-4542-b9ba-b0eaa75941e4@github.com>
Message-ID: <-9fdkta4gj5UUkFxpgUAsFfAR1jWuWPLz6G7XmCONio=.d12a4915-6494-457f-a3c9-26550f0a3c67@github.com>

On Thu, 22 Jun 2023 09:53:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
>> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
>> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
>> But without the entitlement, a core is not generated.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Some adjustments

Yes it must be 'private static Process' . And I moved the javaPath method into the caller ,

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

PR Comment: https://git.openjdk.org/jdk/pull/14562#issuecomment-1602496320

From mbaesken at openjdk.org  Thu Jun 22 12:09:04 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 22 Jun 2023 12:09:04 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work [v2]
In-Reply-To: <GGGG9CKG556EUDfDUmDUMomSxvRB81VyGrt0sbXRchM=.59c82f26-0d1c-43a2-ae8c-d28482b793da@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
 <69LRKDeH8L61mW040KBn5pD_hWg09rVHvI4e1SuMl5g=.b127ba99-3eda-4542-b9ba-b0eaa75941e4@github.com>
 <GGGG9CKG556EUDfDUmDUMomSxvRB81VyGrt0sbXRchM=.59c82f26-0d1c-43a2-ae8c-d28482b793da@github.com>
Message-ID: <BfNd8YxeRyIH31LJU6lPiassDRgN3qd0FK2Ejpc93Vs=.7b1f4461-c90a-4260-9be5-11d18996864d@github.com>

On Thu, 22 Jun 2023 10:54:12 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Looks a bit better. But I think instead of adding a Utils.javaPath() method, you can do all this path handling in Platform.launchCodesignOnJavaBinary(). Then even more code would be shared.

Okay, I  had the idea  to later use  the method javaPath  at some more places, but let's do this separately.

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

PR Comment: https://git.openjdk.org/jdk/pull/14562#issuecomment-1602521579

From clanger at openjdk.org  Thu Jun 22 12:23:07 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 22 Jun 2023 12:23:07 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work [v3]
In-Reply-To: <LdyQw-4zZwjHIW1MC9q43Nekj30shwvyJBaNbPsLg54=.bb966145-68be-4e46-89a5-12c1f0b9048e@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
 <LdyQw-4zZwjHIW1MC9q43Nekj30shwvyJBaNbPsLg54=.bb966145-68be-4e46-89a5-12c1f0b9048e@github.com>
Message-ID: <D19L98CF1JaEwwTVDOmQ8W98G3QvZmaIU6fR9jXzCfg=.2ce8ad35-1f03-4c0e-862f-e1dce10fbd0d@github.com>

On Thu, 22 Jun 2023 11:51:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
>> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
>> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
>> But without the entitlement, a core is not generated.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move javaPath into caller

Looks good to me now.

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

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14562#pullrequestreview-1493063728

From dholmes at openjdk.org  Thu Jun 22 12:24:03 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 22 Jun 2023 12:24:03 GMT
Subject: RFR: 8310618: Test serviceability/sa/ClhsdbDumpclass.java fails
 after 8242152: 'StackMapTable:' missing from stdout/stderr
In-Reply-To: <dBDHdSeZ0XJYik39OxhkIqM1s6xX5luh9ku7nTtBBTw=.71e1b047-2737-4b94-a723-276dac089ac7@github.com>
References: <dBDHdSeZ0XJYik39OxhkIqM1s6xX5luh9ku7nTtBBTw=.71e1b047-2737-4b94-a723-276dac089ac7@github.com>
Message-ID: <xYU5gGIh6WYu4flCy8TZeAb4wSSjDLTzogIgVYN-qH0=.811d92e3-4f84-407b-b624-876596a249e3@github.com>

On Thu, 22 Jun 2023 09:17:46 GMT, Daohan Qu <dqu at openjdk.org> wrote:

> This patch should fix [JDK-8310618](https://bugs.openjdk.org/browse/JDK-8310618). It attempts to correct my errors in fixing [JDK-8242152](https://bugs.openjdk.org/browse/JDK-8242152).

Okay.

Not sure how this ever passed without this, but lets get this fixed ASAP as we have failures in tier1 and tier 3.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14612#pullrequestreview-1493066574

From dqu at openjdk.org  Thu Jun 22 12:28:03 2023
From: dqu at openjdk.org (Daohan Qu)
Date: Thu, 22 Jun 2023 12:28:03 GMT
Subject: RFR: 8310618: Test serviceability/sa/ClhsdbDumpclass.java fails
 after 8242152: 'StackMapTable:' missing from stdout/stderr
In-Reply-To: <xSgsebTZb-KAhcBFEphHcINr0SAShA0hcPrAkaThsEI=.51575568-2772-4445-b318-e339c6b3b694@github.com>
References: <dBDHdSeZ0XJYik39OxhkIqM1s6xX5luh9ku7nTtBBTw=.71e1b047-2737-4b94-a723-276dac089ac7@github.com>
 <xSgsebTZb-KAhcBFEphHcINr0SAShA0hcPrAkaThsEI=.51575568-2772-4445-b318-e339c6b3b694@github.com>
Message-ID: <LePyiCeLijExThhGkzcx4IqEkKXgMIcC0Mvgq75bhRE=.184b9eb9-2bd7-4736-8106-8fdcf8c5812d@github.com>

On Thu, 22 Jun 2023 09:37:40 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> This patch should fix [JDK-8310618](https://bugs.openjdk.org/browse/JDK-8310618). It attempts to correct my errors in fixing [JDK-8242152](https://bugs.openjdk.org/browse/JDK-8242152).
>
> Yes, looks good. 8-)

Thanks a lot for your help and reviews! @kevinjwalls and @dholmes-ora

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

PR Comment: https://git.openjdk.org/jdk/pull/14612#issuecomment-1602546978

From dqu at openjdk.org  Thu Jun 22 12:40:05 2023
From: dqu at openjdk.org (Daohan Qu)
Date: Thu, 22 Jun 2023 12:40:05 GMT
Subject: RFR: 8310618: Test serviceability/sa/ClhsdbDumpclass.java fails
 after 8242152: 'StackMapTable:' missing from stdout/stderr
In-Reply-To: <dBDHdSeZ0XJYik39OxhkIqM1s6xX5luh9ku7nTtBBTw=.71e1b047-2737-4b94-a723-276dac089ac7@github.com>
References: <dBDHdSeZ0XJYik39OxhkIqM1s6xX5luh9ku7nTtBBTw=.71e1b047-2737-4b94-a723-276dac089ac7@github.com>
Message-ID: <BsxU3qm15RWoxqgWmgQz6NQuQIX1N4c5ApX6pjjmSQI=.1577e10f-119b-4091-8a2d-81b9126eb76b@github.com>

On Thu, 22 Jun 2023 09:17:46 GMT, Daohan Qu <dqu at openjdk.org> wrote:

> This patch should fix [JDK-8310618](https://bugs.openjdk.org/browse/JDK-8310618). It attempts to correct my errors in fixing [JDK-8242152](https://bugs.openjdk.org/browse/JDK-8242152).

The failure in GHA on `linux-x86` is in `test/langtools/tools/javac/varargs/warning/Warn5.java`, which seems unrelated to this PR. It is sort of like [this issue](https://bugs.openjdk.org/browse/JDK-8280029).

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

PR Comment: https://git.openjdk.org/jdk/pull/14612#issuecomment-1602563023

From kevinw at openjdk.org  Thu Jun 22 13:18:10 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 22 Jun 2023 13:18:10 GMT
Subject: RFR: 8310618: Test serviceability/sa/ClhsdbDumpclass.java fails
 after 8242152: 'StackMapTable:' missing from stdout/stderr
In-Reply-To: <dBDHdSeZ0XJYik39OxhkIqM1s6xX5luh9ku7nTtBBTw=.71e1b047-2737-4b94-a723-276dac089ac7@github.com>
References: <dBDHdSeZ0XJYik39OxhkIqM1s6xX5luh9ku7nTtBBTw=.71e1b047-2737-4b94-a723-276dac089ac7@github.com>
Message-ID: <BYLs6HT3oL4BUgpbbJkwaeyomZFHmTsi1RrdM0Ncrhc=.e4c2972b-eb3f-4a08-838f-aee3bf212117@github.com>

On Thu, 22 Jun 2023 09:17:46 GMT, Daohan Qu <dqu at openjdk.org> wrote:

> This patch should fix [JDK-8310618](https://bugs.openjdk.org/browse/JDK-8310618). It attempts to correct my errors in fixing [JDK-8242152](https://bugs.openjdk.org/browse/JDK-8242152).

Right, the langtools 32-bit failure does not relate to this.

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

PR Comment: https://git.openjdk.org/jdk/pull/14612#issuecomment-1602620081

From dqu at openjdk.org  Thu Jun 22 13:18:11 2023
From: dqu at openjdk.org (Daohan Qu)
Date: Thu, 22 Jun 2023 13:18:11 GMT
Subject: Integrated: 8310618: Test serviceability/sa/ClhsdbDumpclass.java fails
 after 8242152: 'StackMapTable:' missing from stdout/stderr
In-Reply-To: <dBDHdSeZ0XJYik39OxhkIqM1s6xX5luh9ku7nTtBBTw=.71e1b047-2737-4b94-a723-276dac089ac7@github.com>
References: <dBDHdSeZ0XJYik39OxhkIqM1s6xX5luh9ku7nTtBBTw=.71e1b047-2737-4b94-a723-276dac089ac7@github.com>
Message-ID: <bfZuUYLsTIjHExN_fKtIw7lJljIxAqn0InLZAWOKrZA=.413018e8-f5b6-445b-9086-254adab0b666@github.com>

On Thu, 22 Jun 2023 09:17:46 GMT, Daohan Qu <dqu at openjdk.org> wrote:

> This patch should fix [JDK-8310618](https://bugs.openjdk.org/browse/JDK-8310618). It attempts to correct my errors in fixing [JDK-8242152](https://bugs.openjdk.org/browse/JDK-8242152).

This pull request has now been integrated.

Changeset: 370b8b26
Author:    Daohan Qu <dqu at openjdk.org>
Committer: Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/370b8b2644e8951ba177c39199036c79ecf49401
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8310618: Test serviceability/sa/ClhsdbDumpclass.java fails after 8242152: 'StackMapTable:' missing from stdout/stderr

Reviewed-by: kevinw, dholmes

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

PR: https://git.openjdk.org/jdk/pull/14612

From dcubed at openjdk.org  Thu Jun 22 13:48:13 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 22 Jun 2023 13:48:13 GMT
Subject: RFR: 8242152: SA does not include StackMapTables when dumping
 .class files [v3]
In-Reply-To: <VnJD6sy-w0jZDFFK23NEl7hw82JzsLtazQTD4-zScmQ=.90b285d8-51b9-4bbb-920f-160eaf273ea4@github.com>
References: <pBErA6eLKjV5Ydj7YKeOTkHW4VvuaylzXSdt2-QG2PE=.d4b64495-fbfd-467b-ad70-448e71fb3b1b@github.com>
 <VnJD6sy-w0jZDFFK23NEl7hw82JzsLtazQTD4-zScmQ=.90b285d8-51b9-4bbb-920f-160eaf273ea4@github.com>
Message-ID: <dehvSkdChJAp3AeMwsF81pR04zLEsTL8BQyfyc4Hntc=.9ada12bc-db26-4519-944c-66a329f53c79@github.com>

On Thu, 22 Jun 2023 04:00:14 GMT, Daohan Qu <dqu at openjdk.org> wrote:

>> This patch adds `StackMapTable` for the class files generated by `clhsdb`'s `buildreplayjars` command. This bug manifests itself during my diagnosing [JDK-8309751](https://bugs.openjdk.org/browse/JDK-8309751) and needs to be fixed first.
>> 
>> I have run jtreg test `tier1-3` of release build on x86 linux finding only one failure in `tier2` caused by [JDK-8309214](https://bugs.openjdk.org/browse/JDK-8309214). `jtreg:test/hotspot/jtreg/serviceability` and `jtreg:test/jdk/sun/tools/` also passed.
>
> Daohan Qu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a simple check

Folks the GHA for this PR reported a failure in serviceability/sa/ClhsdbDumpclass
on windows-x64 so that should have been a red flag that something was amiss.

The actual integration reported failures on windows-x64, linux-aarch64 and linux-x64
in Mach5 Tier1. Mach5 Tier3 reports a total of 14 failures on the same three platforms.
Mach5 Tier4 reports 3 failures so far on the same three platforms.

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

PR Comment: https://git.openjdk.org/jdk/pull/14556#issuecomment-1602666849

From dqu at openjdk.org  Thu Jun 22 13:51:15 2023
From: dqu at openjdk.org (Daohan Qu)
Date: Thu, 22 Jun 2023 13:51:15 GMT
Subject: RFR: 8242152: SA does not include StackMapTables when dumping
 .class files [v3]
In-Reply-To: <dehvSkdChJAp3AeMwsF81pR04zLEsTL8BQyfyc4Hntc=.9ada12bc-db26-4519-944c-66a329f53c79@github.com>
References: <pBErA6eLKjV5Ydj7YKeOTkHW4VvuaylzXSdt2-QG2PE=.d4b64495-fbfd-467b-ad70-448e71fb3b1b@github.com>
 <VnJD6sy-w0jZDFFK23NEl7hw82JzsLtazQTD4-zScmQ=.90b285d8-51b9-4bbb-920f-160eaf273ea4@github.com>
 <dehvSkdChJAp3AeMwsF81pR04zLEsTL8BQyfyc4Hntc=.9ada12bc-db26-4519-944c-66a329f53c79@github.com>
Message-ID: <p63qoJXiApybHrjTSrZqUTDtFiHYgv8nQxSujFMDGWw=.dc5fcfb5-4bb3-480b-9a6a-56bb6e8792bd@github.com>

On Thu, 22 Jun 2023 13:44:53 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Daohan Qu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add a simple check
>
> Folks the GHA for this PR reported a failure in serviceability/sa/ClhsdbDumpclass
> on windows-x64 so that should have been a red flag that something was amiss.
> 
> The actual integration reported failures on windows-x64, linux-aarch64 and linux-x64
> in Mach5 Tier1. Mach5 Tier3 reports a total of 14 failures on the same three platforms.
> Mach5 Tier4 reports 3 failures so far on the same three platforms.

Hi, @dcubed-ojdk, yes and it should have been fixed in this PR #14612.

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

PR Comment: https://git.openjdk.org/jdk/pull/14556#issuecomment-1602673944

From alanb at openjdk.org  Thu Jun 22 14:23:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 Jun 2023 14:23:04 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar
In-Reply-To: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
Message-ID: <CXXV_lxlp7_Ntc0hbwPmVezF5PNqfm3oQpiY4HLl6TE=.a8b48f90-8e50-4022-9280-2e54933289a9@github.com>

On Wed, 21 Jun 2023 15:18:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted.

src/java.sql/share/classes/java/sql/DriverManager.java line 658:

> 656:          * (which is invoking this class indirectly)
> 657:          * classloader, so that the JDBC driver class outside the image
> 658:          * can be loaded from here.

This code should probably be changed to use VM.isSystemDomainLoader(callerCL).

I think the comment should be replaced because it doesn't match what it actually does and it's nothing to do with the whether the JDBC driver is in the run-time image or not. How about:

"If the caller is defined to the bootstrap or platform class loader then use the Thread CCL as the initiating class loader so that a JDBC on the class path, or bundled with an application, is found."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1238604300

From duke at openjdk.org  Thu Jun 22 15:37:11 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Thu, 22 Jun 2023 15:37:11 GMT
Subject: RFR: 8309979: BootstrapMethods attribute is missing in class files
 recreated by SA [v3]
In-Reply-To: <nSooA6CtKm8LsaxzYdqJ6mtVV0os-kT5F2xNvYI4lJo=.c27bd28e-88d3-4bcb-ac3d-9036140eeff0@github.com>
References: <nSooA6CtKm8LsaxzYdqJ6mtVV0os-kT5F2xNvYI4lJo=.c27bd28e-88d3-4bcb-ac3d-9036140eeff0@github.com>
Message-ID: <AP8yKMhhMNIqR5yvcLylrZcoiMh7riMYbxK4jpAwpCs=.79aa5a8f-670b-43d2-815c-245fe8d47868@github.com>

> Please review this PR that extends SA to write BootstrapMethods attribute when dumping the class files.
> 
> Tested it by dumping the class file for java/lang/String and comparing the BootstrapMethods attribute shown by javap for the original and the dumped class.

Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:

  Add comment about the layout of operands array in constant pool
  
  Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14495/files
  - new: https://git.openjdk.org/jdk/pull/14495/files/3a7ad373..4cb63978

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14495&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14495&range=01-02

  Stats: 15 lines in 1 file changed: 15 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14495.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14495/head:pull/14495

PR: https://git.openjdk.org/jdk/pull/14495

From duke at openjdk.org  Thu Jun 22 16:13:03 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Thu, 22 Jun 2023 16:13:03 GMT
Subject: RFR: 8309979: BootstrapMethods attribute is missing in class files
 recreated by SA [v2]
In-Reply-To: <BcYUruTksAAC-JjG4G97NDGp-757WOzZgZjfjJjg2LA=.9e7ef15b-b1cf-430f-85cb-c9ca06576b96@github.com>
References: <nSooA6CtKm8LsaxzYdqJ6mtVV0os-kT5F2xNvYI4lJo=.c27bd28e-88d3-4bcb-ac3d-9036140eeff0@github.com>
 <i3PjGx_wbQ63SlwcWL5eBr28sDUb1_dPQ8Q0P3Qgzds=.5f11a8e5-714c-45c0-87e6-e612bb50b28b@github.com>
 <BcYUruTksAAC-JjG4G97NDGp-757WOzZgZjfjJjg2LA=.9e7ef15b-b1cf-430f-85cb-c9ca06576b96@github.com>
Message-ID: <qu7fBUROq67BjS_SohvC0J-ivzwRpZXH168nsve-66Y=.6bcc526f-b04c-44d8-859c-d516a43067bc@github.com>

On Thu, 22 Jun 2023 03:21:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Do we have any automatic test coverage for this?

Nope, I don't think there is any test for BootstrapMethods. As mentioned [here](https://github.com/openjdk/jdk/pull/14556#issuecomment-1601946451) the existing tests - ClhsdbDumpclass.java and TestClassDump.java - are very basic.
I think there is scope for improving testing so that SA's dump feature does not become stale over a period of time as new attributes/tags are added to the classfile format.
I am thinking of a comprehensive test that creates a classfile with specific attribute,  load it in the VM, dump that class file using SA, then disassemble the generated class file to check for the presence of the attribute. We would also need some mechanism to ensure all attributes and cp tags supported by the VM level being tested are covered. Does that sound feasible?

> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPool.java line 475:
> 
>> 473:     if (operands != null) {
>> 474:       count = getOperandOffsetAt(operands, 0) / 2;
>> 475:     }
> 
> Nit: Could you, please, add a small comment why the bootstrap methods count is calculated this way?

Done.

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

PR Comment: https://git.openjdk.org/jdk/pull/14495#issuecomment-1602943392
PR Review Comment: https://git.openjdk.org/jdk/pull/14495#discussion_r1238752462

From asemenov at openjdk.org  Thu Jun 22 17:25:08 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 22 Jun 2023 17:25:08 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v7]
In-Reply-To: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
Message-ID: <YFU72ByH9nRD1kcivWlr-gj7NifaytNn1zaYiCPJ7w4=.f751154b-aedc-4dfa-98b9-3c07b3027bf2@github.com>

> 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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14033/files
  - new: https://git.openjdk.org/jdk/pull/14033/files/842d33d8..c4ca2205

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=05-06

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14033.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14033/head:pull/14033

PR: https://git.openjdk.org/jdk/pull/14033

From asemenov at openjdk.org  Thu Jun 22 17:25:10 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 22 Jun 2023 17:25:10 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v6]
In-Reply-To: <xyC94f3rya2zlmfsqw0_SWQgYwdzfjd0TWcVHvye0as=.a02de106-6ca2-4ef8-bca4-019854019348@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <MLeeOEZNEOO96LlsTWqsL7v2VU3Xk8gLWxE6ZA8HEl8=.90a7959a-6126-40f3-a67b-738a5eb50efd@github.com>
 <xyC94f3rya2zlmfsqw0_SWQgYwdzfjd0TWcVHvye0as=.a02de106-6ca2-4ef8-bca4-019854019348@github.com>
Message-ID: <e_CKdXAilBPQu8gZ3d6XcuvG-5B7XGl6fb5gSevUjlw=.d286a23d-f504-454d-9611-7c6eb8c64084@github.com>

On Thu, 22 Jun 2023 09:58:49 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 260:
> 
>> 258:         DISABLED_WARNINGS_clang_aix_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \
>> 259:         DISABLED_WARNINGS_clang_aix_awt_InputMethod.c := sign-compare, \
>> 260:         DISABLED_WARNINGS_clang_screencast_pipewire.c := format-nonliteral, \
> 
> move this one closer to the other clang (non-aix) suppressions

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1238824459

From mchung at openjdk.org  Thu Jun 22 18:18:02 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 22 Jun 2023 18:18:02 GMT
Subject: RFR: 8310628: GcInfoBuilder.c missing JNI Exception checks
In-Reply-To: <87ZNvqRyVQt6jH_m0k0e6rp3ZgtEqmsHucDrNz27DSA=.985f5cc9-8938-4f70-89fa-35c93cb6606f@github.com>
References: <87ZNvqRyVQt6jH_m0k0e6rp3ZgtEqmsHucDrNz27DSA=.985f5cc9-8938-4f70-89fa-35c93cb6606f@github.com>
Message-ID: <CUjtDlo3MlhBhfQ90WtZwLxAqs23GjY9GCqCVRLdNug=.af07f38b-2fbe-4ccb-9e93-cc3191b653b7@github.com>

On Thu, 22 Jun 2023 10:10:07 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> JNI calls were identified, where we do not check for a pending Exception afterwards.
> 
> (JDK-8162530 cleaned up up some of these kind of issues some years back, but more were found.)
> 
> I tested a code change to manually create an Exception before some of the new ExceptionCheck calls, and this is correctly recognised, we see an Exception thrown by the native getLastGcInfo0, e.g. 
> 
> java.lang.NullPointerException: XXX Test Exception
>         at jdk.management/com.sun.management.internal.GcInfoBuilder.getLastGcInfo0(Native Method)
>         at jdk.management/com.sun.management.internal.GcInfoBuilder.getLastGcInfo(GcInfoBuilder.java:77)
>         at jdk.management/com.sun.management.internal.GarbageCollectorExtImpl.getLastGcInfo(GarbageCollectorExtImpl.java:69)
>         at LastGCInfo.main(LastGCInfo.java:53)
>         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>         at java.base/java.lang.reflect.Method.invoke(Method.java:580)
>         at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
>         at java.base/java.lang.Thread.run(Thread.java:1570)
> 
> Tested with all of test/jdk/com/sun/management including test/jdk/com/sun/management/GarbageCollectorMXBean/LastGCInfo.java

Looks fine.   It may worth refactoring the code to set an element in an utility method.

    jobject obj = JNU_NewObjectByName(env, class_name, signature, value);
    if ((*env)->ExceptionCheck(env)) {
        return;
    }
    (*env)->SetObjectArrayElement(env, array, index, obj);

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

PR Review: https://git.openjdk.org/jdk/pull/14613#pullrequestreview-1493765649

From kevinw at openjdk.org  Thu Jun 22 21:00:02 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 22 Jun 2023 21:00:02 GMT
Subject: RFR: 8310628: GcInfoBuilder.c missing JNI Exception checks
In-Reply-To: <CUjtDlo3MlhBhfQ90WtZwLxAqs23GjY9GCqCVRLdNug=.af07f38b-2fbe-4ccb-9e93-cc3191b653b7@github.com>
References: <87ZNvqRyVQt6jH_m0k0e6rp3ZgtEqmsHucDrNz27DSA=.985f5cc9-8938-4f70-89fa-35c93cb6606f@github.com>
 <CUjtDlo3MlhBhfQ90WtZwLxAqs23GjY9GCqCVRLdNug=.af07f38b-2fbe-4ccb-9e93-cc3191b653b7@github.com>
Message-ID: <WbWiegv3Z8rmB9OKZkDCwlOlQbAl5aWJIAdpIH-KgMc=.1393fb72-35b2-44d5-b152-ba27d86af9e6@github.com>

On Thu, 22 Jun 2023 18:14:48 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Looks fine. It may worth refactoring the code to set an element in an utility method.
> 
> ```
>     jobject obj = JNU_NewObjectByName(env, class_name, signature, value);
>     if ((*env)->ExceptionCheck(env)) {
>         return;
>     }
>     (*env)->SetObjectArrayElement(env, array, index, obj);
> ```

Thanks Mandy,

I would suggest to just do this simple change as it seems most likely to be correct.  We are here because a tool found the missing exception checks, not because this code is looked at by people frequently.  I think the common helper method might be more complex than what we have here.

This file rarely changes, these methods here haven't changed in forever.
There was the previous JNI exception change in this file in 2017, affecting other methods.
There are a couple of other changes in the file, also affecting other methods, and then it's the initial load in jdk8 in 2007 and probably they are the same before that.

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

PR Comment: https://git.openjdk.org/jdk/pull/14613#issuecomment-1603305305

From amenkov at openjdk.org  Fri Jun 23 02:05:24 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 23 Jun 2023 02:05:24 GMT
Subject: RFR: JDK-8310066: Improve test coverage for JVMTI GetThreadState on
 carrier and mounted vthread
Message-ID: <_8UnxXrT842BKmJ98GlmJyL21yzM0dhGOkeeK0Mnf2g=.c90b2826-922c-4838-b816-8bf3b5933d87@github.com>

This is follow-up JDK-8307153/JDK-8309612 (JVMTI GetThreadState on carrier should return STATE_WAITING)
New test tests GetThreadState for different thread states.
The test detected a bug in the implementation, new issue is created: JDK-8310584
Corresponding testcases are commented now in the test, fix for JDK-8310584 will uncomment them

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

Commit messages:
 - Added GetThreadState test

Changes: https://git.openjdk.org/jdk/pull/14622/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14622&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310066
  Stats: 455 lines in 2 files changed: 455 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14622.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14622/head:pull/14622

PR: https://git.openjdk.org/jdk/pull/14622

From jwaters at openjdk.org  Fri Jun 23 02:29:07 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Jun 2023 02:29:07 GMT
Subject: RFR: 8305341: Alignment should be enforced by alignas instead of
 compiler specific attributes [v5]
In-Reply-To: <OO54CVLdk0uWvMSIzS8ePDvGv2rbYJNQlqk7QZTyRiM=.4dabc87c-f302-4b61-8d02-9678ad243a5b@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
 <OO54CVLdk0uWvMSIzS8ePDvGv2rbYJNQlqk7QZTyRiM=.4dabc87c-f302-4b61-8d02-9678ad243a5b@github.com>
Message-ID: <eEbDYpSwsLcib5N30VkZvRcHoIpGzQPSs3o4BVhzsuw=.f3f36344-3e98-4bd9-99b2-c03a2f76eb0a@github.com>

On Tue, 20 Jun 2023 07:20:12 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements
>
> Julian Waters has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Whitespace
>  - Revert
>  - _MSC_VER

@djelinski Sorry for the tag, it's just that this PR has been collecting dust for months now

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

PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1603602062

From jwaters at openjdk.org  Fri Jun 23 02:43:38 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 23 Jun 2023 02:43:38 GMT
Subject: RFR: 8305341: Alignment should be enforced by alignas instead of
 compiler specific attributes [v6]
In-Reply-To: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
Message-ID: <1jA_lH7-3g7zTrXOZIP4LnTjVWrHX80RBOdqAbGKzsQ=.a2118233-3311-49b9-acaf-c4241091d928@github.com>

> C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements

Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Merge branch 'openjdk:master' into patch-6
 - Whitespace
 - Revert
 - _MSC_VER
 - Restore visCPP
 - Restore gcc attribute
 - Revert gcc
 - Revert
 - Semicolon
 - gcc offset_of
 - ... and 8 more: https://git.openjdk.org/jdk/compare/5a82fa3b...6c289fb3

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

Changes: https://git.openjdk.org/jdk/pull/13258/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13258&range=05
  Stats: 11 lines in 3 files changed: 5 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/13258.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13258/head:pull/13258

PR: https://git.openjdk.org/jdk/pull/13258

From dholmes at openjdk.org  Fri Jun 23 04:40:01 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 23 Jun 2023 04:40:01 GMT
Subject: RFR: 8310628: GcInfoBuilder.c missing JNI Exception checks
In-Reply-To: <87ZNvqRyVQt6jH_m0k0e6rp3ZgtEqmsHucDrNz27DSA=.985f5cc9-8938-4f70-89fa-35c93cb6606f@github.com>
References: <87ZNvqRyVQt6jH_m0k0e6rp3ZgtEqmsHucDrNz27DSA=.985f5cc9-8938-4f70-89fa-35c93cb6606f@github.com>
Message-ID: <-spoFoP1Jnd7kgwIOERocunOhrAr6INDRWMpHLqsoj0=.1eb7b43b-39d1-4095-adb2-5af41c23c083@github.com>

On Thu, 22 Jun 2023 10:10:07 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> JNI calls were identified, where we do not check for a pending Exception afterwards.
> 
> (JDK-8162530 cleaned up up some of these kind of issues some years back, but more were found.)
> 
> I tested a code change to manually create an Exception before some of the new ExceptionCheck calls, and this is correctly recognised, we see an Exception thrown by the native getLastGcInfo0, e.g. 
> 
> java.lang.NullPointerException: XXX Test Exception
>         at jdk.management/com.sun.management.internal.GcInfoBuilder.getLastGcInfo0(Native Method)
>         at jdk.management/com.sun.management.internal.GcInfoBuilder.getLastGcInfo(GcInfoBuilder.java:77)
>         at jdk.management/com.sun.management.internal.GarbageCollectorExtImpl.getLastGcInfo(GarbageCollectorExtImpl.java:69)
>         at LastGCInfo.main(LastGCInfo.java:53)
>         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>         at java.base/java.lang.reflect.Method.invoke(Method.java:580)
>         at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
>         at java.base/java.lang.Thread.run(Thread.java:1570)
> 
> Tested with all of test/jdk/com/sun/management including test/jdk/com/sun/management/GarbageCollectorMXBean/LastGCInfo.java

Seems fine to me.

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14613#pullrequestreview-1494377907

From djelinski at openjdk.org  Fri Jun 23 05:58:15 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 23 Jun 2023 05:58:15 GMT
Subject: RFR: 8305341: Alignment should be enforced by alignas instead of
 compiler specific attributes [v5]
In-Reply-To: <eEbDYpSwsLcib5N30VkZvRcHoIpGzQPSs3o4BVhzsuw=.f3f36344-3e98-4bd9-99b2-c03a2f76eb0a@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
 <OO54CVLdk0uWvMSIzS8ePDvGv2rbYJNQlqk7QZTyRiM=.4dabc87c-f302-4b61-8d02-9678ad243a5b@github.com>
 <eEbDYpSwsLcib5N30VkZvRcHoIpGzQPSs3o4BVhzsuw=.f3f36344-3e98-4bd9-99b2-c03a2f76eb0a@github.com>
Message-ID: <0uCYsojlqYE-BhXPzK4Ne8u0I814yw5aWnNgAwYoeBc=.55117431-5a01-444e-8903-86779148ea78@github.com>

On Fri, 23 Jun 2023 02:25:47 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Whitespace
>>  - Revert
>>  - _MSC_VER
>
> @djelinski Sorry for the tag, it's just that this PR has been collecting dust for months now

Hi @TheShermanTanker these alignment instructions were introduced in JDK-8220348 and JDK-8239856 to deal with Windows 32 failures. Windows 32 build is going away soon. As far as I could tell, the declspec was only introduced to deal with an overzealous assert.

@TheRealMDoerr @RealCLanger @tstuefe @sspitsyn since you were responsible for the introduction of the alignment specifiers, could you help with reviewing this?

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

PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1603717283

From djelinski at openjdk.org  Fri Jun 23 06:22:06 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 23 Jun 2023 06:22:06 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v6]
In-Reply-To: <xyC94f3rya2zlmfsqw0_SWQgYwdzfjd0TWcVHvye0as=.a02de106-6ca2-4ef8-bca4-019854019348@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <MLeeOEZNEOO96LlsTWqsL7v2VU3Xk8gLWxE6ZA8HEl8=.90a7959a-6126-40f3-a67b-738a5eb50efd@github.com>
 <xyC94f3rya2zlmfsqw0_SWQgYwdzfjd0TWcVHvye0as=.a02de106-6ca2-4ef8-bca4-019854019348@github.com>
Message-ID: <X88jHsrpGh8-OhkjdpNOUXtJUiz9e_2P0tbSRw-ecNQ=.2572f718-d8ea-4acb-9ba4-54fa78af8e0d@github.com>

On Thu, 22 Jun 2023 09:58:19 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 241:
> 
>> 239:                 DISABLED_WARNINGS_gcc_OGLPaints.c := format-nonliteral, \
>> 240:                 DISABLED_WARNINGS_gcc_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \
>> 241:                 DISABLED_WARNINGS_gcc_X11SurfaceData.c := implicit-fallthrough pointer-to-int-cast, \
> 
> Suggestion:
> 
>         DISABLED_WARNINGS_gcc_GLXSurfaceData.c := unused-function, \
>         DISABLED_WARNINGS_gcc_gtk2_interface.c := parentheses type-limits, \
>         DISABLED_WARNINGS_gcc_gtk3_interface.c := parentheses type-limits unused-function, \
>         DISABLED_WARNINGS_gcc_OGLBufImgOps.c := format-nonliteral, \
>         DISABLED_WARNINGS_gcc_OGLPaints.c := format-nonliteral, \
>         DISABLED_WARNINGS_gcc_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \
>         DISABLED_WARNINGS_gcc_X11SurfaceData.c := implicit-fallthrough pointer-to-int-cast, \

Please remove the extra spaces.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1239364317

From asemenov at openjdk.org  Fri Jun 23 08:03:45 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Fri, 23 Jun 2023 08:03:45 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v8]
In-Reply-To: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
Message-ID: <GCgWk1vF_zbGtJGvtEuOTzKmDLOrscBJq_o6zO1rRzM=.d851f275-2c6c-4dda-91fe-a456117da44f@github.com>

> 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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14033/files
  - new: https://git.openjdk.org/jdk/pull/14033/files/c4ca2205..92f629f7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=06-07

  Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/14033.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14033/head:pull/14033

PR: https://git.openjdk.org/jdk/pull/14033

From asemenov at openjdk.org  Fri Jun 23 08:09:05 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Fri, 23 Jun 2023 08:09:05 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v6]
In-Reply-To: <X88jHsrpGh8-OhkjdpNOUXtJUiz9e_2P0tbSRw-ecNQ=.2572f718-d8ea-4acb-9ba4-54fa78af8e0d@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <MLeeOEZNEOO96LlsTWqsL7v2VU3Xk8gLWxE6ZA8HEl8=.90a7959a-6126-40f3-a67b-738a5eb50efd@github.com>
 <xyC94f3rya2zlmfsqw0_SWQgYwdzfjd0TWcVHvye0as=.a02de106-6ca2-4ef8-bca4-019854019348@github.com>
 <X88jHsrpGh8-OhkjdpNOUXtJUiz9e_2P0tbSRw-ecNQ=.2572f718-d8ea-4acb-9ba4-54fa78af8e0d@github.com>
Message-ID: <uFToDpeYUWFQyhvBB5DMIvAYOdiUDq-KP-R6v64A51g=.361ef91f-3e20-4be7-b63e-f3774cb9128c@github.com>

On Fri, 23 Jun 2023 06:19:31 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 241:
>> 
>>> 239:                 DISABLED_WARNINGS_gcc_OGLPaints.c := format-nonliteral, \
>>> 240:                 DISABLED_WARNINGS_gcc_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \
>>> 241:                 DISABLED_WARNINGS_gcc_X11SurfaceData.c := implicit-fallthrough pointer-to-int-cast, \
>> 
>> Suggestion:
>> 
>>         DISABLED_WARNINGS_gcc_GLXSurfaceData.c := unused-function, \
>>         DISABLED_WARNINGS_gcc_gtk2_interface.c := parentheses type-limits, \
>>         DISABLED_WARNINGS_gcc_gtk3_interface.c := parentheses type-limits unused-function, \
>>         DISABLED_WARNINGS_gcc_OGLBufImgOps.c := format-nonliteral, \
>>         DISABLED_WARNINGS_gcc_OGLPaints.c := format-nonliteral, \
>>         DISABLED_WARNINGS_gcc_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \
>>         DISABLED_WARNINGS_gcc_X11SurfaceData.c := implicit-fallthrough pointer-to-int-cast, \
>
> Please remove the extra spaces.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1239506015

From djelinski at openjdk.org  Fri Jun 23 08:27:04 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 23 Jun 2023 08:27:04 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v8]
In-Reply-To: <GCgWk1vF_zbGtJGvtEuOTzKmDLOrscBJq_o6zO1rRzM=.d851f275-2c6c-4dda-91fe-a456117da44f@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <GCgWk1vF_zbGtJGvtEuOTzKmDLOrscBJq_o6zO1rRzM=.d851f275-2c6c-4dda-91fe-a456117da44f@github.com>
Message-ID: <6Ii3MX8vMTxkr1M6OSPRK1MC3Mird6O_jeC6topuMdU=.e954d902-8b57-40bf-8fd9-9d88b82cd969@github.com>

On Fri, 23 Jun 2023 08:03:45 GMT, Artem Semenov <asemenov at openjdk.org> 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

LGTM

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14033#pullrequestreview-1494691850

From mbaesken at openjdk.org  Fri Jun 23 08:40:06 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 23 Jun 2023 08:40:06 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work [v3]
In-Reply-To: <LdyQw-4zZwjHIW1MC9q43Nekj30shwvyJBaNbPsLg54=.bb966145-68be-4e46-89a5-12c1f0b9048e@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
 <LdyQw-4zZwjHIW1MC9q43Nekj30shwvyJBaNbPsLg54=.bb966145-68be-4e46-89a5-12c1f0b9048e@github.com>
Message-ID: <y6e_N1LMrTBZdZekhjzGj2KwcMhVO-qFNgnUXudcgE8=.20369c56-290f-4f8c-ae2e-a2399fcde214@github.com>

On Thu, 22 Jun 2023 11:51:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
>> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
>> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
>> But without the entitlement, a core is not generated.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move javaPath into caller

Hi Christoph, thanks for the review !
Chris are you okay with the latest rev.  of this change?

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

PR Comment: https://git.openjdk.org/jdk/pull/14562#issuecomment-1603933840

From mchung at openjdk.org  Fri Jun 23 16:48:05 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 23 Jun 2023 16:48:05 GMT
Subject: RFR: 8310628: GcInfoBuilder.c missing JNI Exception checks
In-Reply-To: <87ZNvqRyVQt6jH_m0k0e6rp3ZgtEqmsHucDrNz27DSA=.985f5cc9-8938-4f70-89fa-35c93cb6606f@github.com>
References: <87ZNvqRyVQt6jH_m0k0e6rp3ZgtEqmsHucDrNz27DSA=.985f5cc9-8938-4f70-89fa-35c93cb6606f@github.com>
Message-ID: <2QzgZXdspymrtX47C9RvNRfhX5TBtfP1dxCXw2mhjO0=.c8b509ab-a8b3-48f5-866a-70e3ca00ded8@github.com>

On Thu, 22 Jun 2023 10:10:07 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> JNI calls were identified, where we do not check for a pending Exception afterwards.
> 
> (JDK-8162530 cleaned up up some of these kind of issues some years back, but more were found.)
> 
> I tested a code change to manually create an Exception before some of the new ExceptionCheck calls, and this is correctly recognised, we see an Exception thrown by the native getLastGcInfo0, e.g. 
> 
> java.lang.NullPointerException: XXX Test Exception
>         at jdk.management/com.sun.management.internal.GcInfoBuilder.getLastGcInfo0(Native Method)
>         at jdk.management/com.sun.management.internal.GcInfoBuilder.getLastGcInfo(GcInfoBuilder.java:77)
>         at jdk.management/com.sun.management.internal.GarbageCollectorExtImpl.getLastGcInfo(GarbageCollectorExtImpl.java:69)
>         at LastGCInfo.main(LastGCInfo.java:53)
>         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>         at java.base/java.lang.reflect.Method.invoke(Method.java:580)
>         at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
>         at java.base/java.lang.Thread.run(Thread.java:1570)
> 
> Tested with all of test/jdk/com/sun/management including test/jdk/com/sun/management/GarbageCollectorMXBean/LastGCInfo.java

Marked as reviewed by mchung (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14613#pullrequestreview-1495483988

From kevinw at openjdk.org  Fri Jun 23 17:42:02 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 23 Jun 2023 17:42:02 GMT
Subject: RFR: 8310628: GcInfoBuilder.c missing JNI Exception checks
In-Reply-To: <87ZNvqRyVQt6jH_m0k0e6rp3ZgtEqmsHucDrNz27DSA=.985f5cc9-8938-4f70-89fa-35c93cb6606f@github.com>
References: <87ZNvqRyVQt6jH_m0k0e6rp3ZgtEqmsHucDrNz27DSA=.985f5cc9-8938-4f70-89fa-35c93cb6606f@github.com>
Message-ID: <iaqEOiLem5hEESqLsO_UrEnL6A8-VSQi65aDGveb2mk=.dc3fb501-cd04-44a4-8c93-b07ed187771c@github.com>

On Thu, 22 Jun 2023 10:10:07 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> JNI calls were identified, where we do not check for a pending Exception afterwards.
> 
> (JDK-8162530 cleaned up up some of these kind of issues some years back, but more were found.)
> 
> I tested a code change to manually create an Exception before some of the new ExceptionCheck calls, and this is correctly recognised, we see an Exception thrown by the native getLastGcInfo0, e.g. 
> 
> java.lang.NullPointerException: XXX Test Exception
>         at jdk.management/com.sun.management.internal.GcInfoBuilder.getLastGcInfo0(Native Method)
>         at jdk.management/com.sun.management.internal.GcInfoBuilder.getLastGcInfo(GcInfoBuilder.java:77)
>         at jdk.management/com.sun.management.internal.GarbageCollectorExtImpl.getLastGcInfo(GarbageCollectorExtImpl.java:69)
>         at LastGCInfo.main(LastGCInfo.java:53)
>         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>         at java.base/java.lang.reflect.Method.invoke(Method.java:580)
>         at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
>         at java.base/java.lang.Thread.run(Thread.java:1570)
> 
> Tested with all of test/jdk/com/sun/management including test/jdk/com/sun/management/GarbageCollectorMXBean/LastGCInfo.java

Thanks David and Mandy for the Reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/14613#issuecomment-1604612071

From kevinw at openjdk.org  Fri Jun 23 17:45:12 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 23 Jun 2023 17:45:12 GMT
Subject: Integrated: 8310628: GcInfoBuilder.c missing JNI Exception checks
In-Reply-To: <87ZNvqRyVQt6jH_m0k0e6rp3ZgtEqmsHucDrNz27DSA=.985f5cc9-8938-4f70-89fa-35c93cb6606f@github.com>
References: <87ZNvqRyVQt6jH_m0k0e6rp3ZgtEqmsHucDrNz27DSA=.985f5cc9-8938-4f70-89fa-35c93cb6606f@github.com>
Message-ID: <ALajfturGvAgeq4x0MIHdePnBXYEbGqGWrv_mhTwj48=.3e8da861-4424-4552-91a1-655c874fb878@github.com>

On Thu, 22 Jun 2023 10:10:07 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> JNI calls were identified, where we do not check for a pending Exception afterwards.
> 
> (JDK-8162530 cleaned up up some of these kind of issues some years back, but more were found.)
> 
> I tested a code change to manually create an Exception before some of the new ExceptionCheck calls, and this is correctly recognised, we see an Exception thrown by the native getLastGcInfo0, e.g. 
> 
> java.lang.NullPointerException: XXX Test Exception
>         at jdk.management/com.sun.management.internal.GcInfoBuilder.getLastGcInfo0(Native Method)
>         at jdk.management/com.sun.management.internal.GcInfoBuilder.getLastGcInfo(GcInfoBuilder.java:77)
>         at jdk.management/com.sun.management.internal.GarbageCollectorExtImpl.getLastGcInfo(GarbageCollectorExtImpl.java:69)
>         at LastGCInfo.main(LastGCInfo.java:53)
>         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>         at java.base/java.lang.reflect.Method.invoke(Method.java:580)
>         at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
>         at java.base/java.lang.Thread.run(Thread.java:1570)
> 
> Tested with all of test/jdk/com/sun/management including test/jdk/com/sun/management/GarbageCollectorMXBean/LastGCInfo.java

This pull request has now been integrated.

Changeset: a9c0a0f6
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a9c0a0f6b915f9ddaa97d83bad4f3c2b38810636
Stats:     29 lines in 1 file changed: 20 ins; 0 del; 9 mod

8310628: GcInfoBuilder.c missing JNI Exception checks

Reviewed-by: mchung, dholmes

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

PR: https://git.openjdk.org/jdk/pull/14613

From kevinw at openjdk.org  Fri Jun 23 19:10:14 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 23 Jun 2023 19:10:14 GMT
Subject: RFR: 8310816: GcInfoBuilder float/double signature mismatch
Message-ID: <51x6x8swNwXsWnSxuskzLe3sF2x8Ke8rUmVA9pJXPBM=.868ffcd7-652a-4bff-9246-6c6e21f785d3@github.com>

Simple typo in a signature which is passed to JNU_NewObjectByName.  The method clearly intentds to pass Float, but uses Double.

This code is probably not invoked, unless there is a GC MXBean with such fields.  I see no straightforward way of testing this explicitly, but the change is tiny.

All tests in test/jdk/com/sun/management still pass.

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

Commit messages:
 - 8310816: GcInfoBuilder float/double signature mismatch

Changes: https://git.openjdk.org/jdk/pull/14631/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14631&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310816
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14631.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14631/head:pull/14631

PR: https://git.openjdk.org/jdk/pull/14631

From never at openjdk.org  Fri Jun 23 19:31:20 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Fri, 23 Jun 2023 19:31:20 GMT
Subject: RFR: 8294316: SA core file support is broken on macosx-x64
 starting with macOS 12.x [v2]
In-Reply-To: <0wPtkRqjB3Nh6LiABARFcqq6UqcCsTNbF1ok1iG0Efw=.af55940f-5b2d-4cfb-b233-066a419bae48@github.com>
References: <0wPtkRqjB3Nh6LiABARFcqq6UqcCsTNbF1ok1iG0Efw=.af55940f-5b2d-4cfb-b233-066a419bae48@github.com>
Message-ID: <tJvVPDUTdKDLNHtqCbkuHrnLxlOfWaXuizfoGXE5NHo=.5983a878-e421-41bc-a0af-fb6f8d9a98da@github.com>

> This is a minor fix to core file reading on macos x.  I can confirm that after this fix I can run the problem listed SA core file tests on Ventura.

Tom Rodriguez has updated the pull request incrementally with three additional commits since the last revision:

 - Flatten nested ifs
 - Adjust ordering of message
 - Adjust printing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14569/files
  - new: https://git.openjdk.org/jdk/pull/14569/files/9852ed16..2ebe4d09

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14569&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14569&range=00-01

  Stats: 12 lines in 1 file changed: 4 ins; 5 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14569.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14569/head:pull/14569

PR: https://git.openjdk.org/jdk/pull/14569

From never at openjdk.org  Fri Jun 23 19:31:21 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Fri, 23 Jun 2023 19:31:21 GMT
Subject: RFR: 8294316: SA core file support is broken on macosx-x64
 starting with macOS 12.x [v2]
In-Reply-To: <aww5nN1uEvwzUzFxX2izy_ewnFTNlJOvriQhuf-bnS8=.7ca30162-6e55-4de9-92cb-e3742d7dea92@github.com>
References: <0wPtkRqjB3Nh6LiABARFcqq6UqcCsTNbF1ok1iG0Efw=.af55940f-5b2d-4cfb-b233-066a419bae48@github.com>
 <aww5nN1uEvwzUzFxX2izy_ewnFTNlJOvriQhuf-bnS8=.7ca30162-6e55-4de9-92cb-e3742d7dea92@github.com>
Message-ID: <WF6DRbv9zOjeo3hEe9G9t7HbfDMFdiWPzHdhMZCTwAw=.0caf6f57-316b-4f92-911a-a729db7e6aeb@github.com>

On Wed, 21 Jun 2023 19:56:58 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Tom Rodriguez has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Flatten nested ifs
>>  - Adjust ordering of message
>>  - Adjust printing
>
> src/jdk.hotspot.agent/macosx/native/libsaproc/ps_core.c line 309:
> 
>> 307:         print_debug("LC_SEGMENT_64 added: nsects=%d fileoff=0x%llx vmaddr=0x%llx vmsize=0x%llx filesize=0x%llx %s\n",
>> 308:                     segcmd.nsects, segcmd.fileoff, segcmd.vmaddr, segcmd.vmsize,
>> 309:                     segcmd.filesize, &segcmd.segname[0]);
> 
> It would be nice to include this print_debug for the `filesize == 0` case. Maybe you can move it outside of the `if` and print `added` or `skipped` conditional on `filesize`.

Good idea.  I've flattened the ifs a little and fixed the message.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14569#discussion_r1240227363

From sspitsyn at openjdk.org  Fri Jun 23 20:51:05 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 23 Jun 2023 20:51:05 GMT
Subject: RFR: 8294316: SA core file support is broken on macosx-x64
 starting with macOS 12.x [v2]
In-Reply-To: <tJvVPDUTdKDLNHtqCbkuHrnLxlOfWaXuizfoGXE5NHo=.5983a878-e421-41bc-a0af-fb6f8d9a98da@github.com>
References: <0wPtkRqjB3Nh6LiABARFcqq6UqcCsTNbF1ok1iG0Efw=.af55940f-5b2d-4cfb-b233-066a419bae48@github.com>
 <tJvVPDUTdKDLNHtqCbkuHrnLxlOfWaXuizfoGXE5NHo=.5983a878-e421-41bc-a0af-fb6f8d9a98da@github.com>
Message-ID: <LYgZO-PnOKBikpcApWXEsV5en2nbD9hWyT0Ks3oIKU8=.a5102ece-d38d-46ad-9eab-a6645f935039@github.com>

On Fri, 23 Jun 2023 19:31:20 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> This is a minor fix to core file reading on macos x.  I can confirm that after this fix I can run the problem listed SA core file tests on Ventura.
>
> Tom Rodriguez has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Flatten nested ifs
>  - Adjust ordering of message
>  - Adjust printing

Update looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14569#pullrequestreview-1495996925

From mchung at openjdk.org  Fri Jun 23 21:00:03 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 23 Jun 2023 21:00:03 GMT
Subject: RFR: 8310816: GcInfoBuilder float/double signature mismatch
In-Reply-To: <51x6x8swNwXsWnSxuskzLe3sF2x8Ke8rUmVA9pJXPBM=.868ffcd7-652a-4bff-9246-6c6e21f785d3@github.com>
References: <51x6x8swNwXsWnSxuskzLe3sF2x8Ke8rUmVA9pJXPBM=.868ffcd7-652a-4bff-9246-6c6e21f785d3@github.com>
Message-ID: <OwO0nA1dO9ymtoHLy1Wf3WLuN04DLraSrxZXoFL5J78=.a7379933-86e3-4bce-b45f-e56e72f839a0@github.com>

On Fri, 23 Jun 2023 18:10:59 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Simple typo in a signature which is passed to JNU_NewObjectByName.  The method clearly intentds to pass Float, but uses Double.
> 
> This code is probably not invoked, unless there is a GC MXBean with such fields.  I see no straightforward way of testing this explicitly, but the change is tiny.
> 
> All tests in test/jdk/com/sun/management still pass.

Marked as reviewed by mchung (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14631#pullrequestreview-1496015078

From dholmes at openjdk.org  Fri Jun 23 21:41:03 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 23 Jun 2023 21:41:03 GMT
Subject: RFR: 8310816: GcInfoBuilder float/double signature mismatch
In-Reply-To: <51x6x8swNwXsWnSxuskzLe3sF2x8Ke8rUmVA9pJXPBM=.868ffcd7-652a-4bff-9246-6c6e21f785d3@github.com>
References: <51x6x8swNwXsWnSxuskzLe3sF2x8Ke8rUmVA9pJXPBM=.868ffcd7-652a-4bff-9246-6c6e21f785d3@github.com>
Message-ID: <wJcq72O4SIB18uZN1DVU1VhPDm3milDec2kTtoQHCIg=.f608ace1-80b7-412c-bdab-14917d898c0f@github.com>

On Fri, 23 Jun 2023 18:10:59 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Simple typo in a signature which is passed to JNU_NewObjectByName.  The method clearly intentds to pass Float, but uses Double.
> 
> This code is probably not invoked, unless there is a GC MXBean with such fields.  I see no straightforward way of testing this explicitly, but the change is tiny.
> 
> All tests in test/jdk/com/sun/management still pass.

Seems an obvious copy'n'paste error, but would result in a null entry in the array.

I can't figure out how this code is triggered by `getLastGcInfo0` so can't say how to test it either.

Hard to imagine removing a null could cause a problem for code accessing the resulting array, so it seems safe in that regard.

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14631#pullrequestreview-1496074434

From amenkov at openjdk.org  Fri Jun 23 23:06:09 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 23 Jun 2023 23:06:09 GMT
Subject: RFR: 8310585: GetThreadState spec mentions undefined
 JVMTI_THREAD_STATE_MONITOR_WAITING
Message-ID: <cS0KuoYy8kK2zVNJ733E-oXIAQyVqDuEgKm9RKKxipk=.5e2c01d5-97f8-4df3-a569-e7f5ea127df0@github.com>

Trivial fix in JVMTI spec.
As it's just a typo, CSR is not required

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

Commit messages:
 - Update jvmti.xml

Changes: https://git.openjdk.org/jdk/pull/14634/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14634&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310585
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14634.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14634/head:pull/14634

PR: https://git.openjdk.org/jdk/pull/14634

From vsitnikov at openjdk.org  Sat Jun 24 06:51:16 2023
From: vsitnikov at openjdk.org (Vladimir Sitnikov)
Date: Sat, 24 Jun 2023 06:51:16 GMT
Subject: RFR: 8298047: Remove all non-significant trailing whitespace from
 properties files [v2]
In-Reply-To: <X1UfghRlNyAzyQCMfM6r9kApI-YH6bAcjUPh8Gha8ZI=.79477f8e-2278-4f1b-904f-a091841dcd5b@github.com>
References: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
 <X1UfghRlNyAzyQCMfM6r9kApI-YH6bAcjUPh8Gha8ZI=.79477f8e-2278-4f1b-904f-a091841dcd5b@github.com>
Message-ID: <_N1D3JRNf6qFNvV8d2XZMdDWO7BC8pk58CR7fVNTDcM=.bad91d00-fd4e-4a16-a9fc-f274d38f213d@github.com>

On Mon, 16 Jan 2023 16:50:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an attempt to remove all trailing whitespace from properties files, and enable a jcheck verification that they did not come back, similar to other source code. It turned out that this was not so simple, however, since trailing whitespace in values is actually significant in properties files.
>> 
>> To address this, I have opened four bugs on different component teams to either remove the trailing significant whitespace (if it is there erroneously), or convert it to the unicode sequence `\u0020`: [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046).
>> 
>> That leaves all the other trailing spaces, in blank lines and in the end of comments. These serve no purpose and should just be removed, and is what this issue concerns.
>> 
>> When this and the four "significant whitespace" bugs are all finally integrated, we can finally turn on the verification in jcheck for properties files as well.
>> 
>> The changes in this PR is based on [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), in #10792. I have restored all the "delete trailing whitespace" changes, except for those with significance. These changes were in turned created by  running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into properties-eol-clean-safe
>  - 8298047: Remove all non-significant trailing whitespace from properties files

I've posted the suggetion to add .editorconfig on ide-support-dev, however, the list does not seem to be active: https://mail.openjdk.org/pipermail/ide-support-dev/2023-June/000281.html

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

PR Comment: https://git.openjdk.org/jdk/pull/11491#issuecomment-1605290913

From sspitsyn at openjdk.org  Sat Jun 24 23:51:02 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 24 Jun 2023 23:51:02 GMT
Subject: RFR: 8310585: GetThreadState spec mentions undefined
 JVMTI_THREAD_STATE_MONITOR_WAITING
In-Reply-To: <cS0KuoYy8kK2zVNJ733E-oXIAQyVqDuEgKm9RKKxipk=.5e2c01d5-97f8-4df3-a569-e7f5ea127df0@github.com>
References: <cS0KuoYy8kK2zVNJ733E-oXIAQyVqDuEgKm9RKKxipk=.5e2c01d5-97f8-4df3-a569-e7f5ea127df0@github.com>
Message-ID: <kd5DjxAn35km_G2a6IObV-Eitd-hcKhlPz-hnR1Ch80=.3d6a229d-5ac7-4ac2-845f-c2f91c890dc5@github.com>

On Fri, 23 Jun 2023 22:59:54 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Trivial fix in JVMTI spec.
> As it's just a typo, CSR is not required

Nice catch! Looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14634#pullrequestreview-1496832683

From dnsimon at openjdk.org  Sun Jun 25 07:05:04 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Sun, 25 Jun 2023 07:05:04 GMT
Subject: RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit
Message-ID: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>

The VMSupport class is required for translating an exception between the HotSpot and libgraal heaps.
Loading it lazily can result in a loading exception, obscuring the exception being translated.
To avoid this, VMSupport is loaded eagerly along with the other vmClasses.

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

Commit messages:
 - resolve VMSupport at bootstrap to avoid nested exception in ExceptionTranslation::doit

Changes: https://git.openjdk.org/jdk/pull/14641/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14641&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310829
  Stats: 19 lines in 5 files changed: 1 ins; 11 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/14641.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14641/head:pull/14641

PR: https://git.openjdk.org/jdk/pull/14641

From jwaters at openjdk.org  Sun Jun 25 16:01:26 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 25 Jun 2023 16:01:26 GMT
Subject: RFR: 8305341: Alignment should be enforced by alignas instead of
 compiler specific attributes [v6]
In-Reply-To: <1jA_lH7-3g7zTrXOZIP4LnTjVWrHX80RBOdqAbGKzsQ=.a2118233-3311-49b9-acaf-c4241091d928@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
 <1jA_lH7-3g7zTrXOZIP4LnTjVWrHX80RBOdqAbGKzsQ=.a2118233-3311-49b9-acaf-c4241091d928@github.com>
Message-ID: <4byEsN8A77TyPs1uUYoCajUiOUy54KE1TRl_PeQG7MA=.3ead4dde-1553-4499-adc0-9a2ba6d53022@github.com>

On Fri, 23 Jun 2023 02:43:38 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Merge branch 'openjdk:master' into patch-6
>  - Whitespace
>  - Revert
>  - _MSC_VER
>  - Restore visCPP
>  - Restore gcc attribute
>  - Revert gcc
>  - Revert
>  - Semicolon
>  - gcc offset_of
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/5a82fa3b...6c289fb3

Bumping

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

PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1606141758

From mdoerr at openjdk.org  Sun Jun 25 16:37:11 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Sun, 25 Jun 2023 16:37:11 GMT
Subject: RFR: 8305341: Alignment should be enforced by alignas instead of
 compiler specific attributes [v6]
In-Reply-To: <1jA_lH7-3g7zTrXOZIP4LnTjVWrHX80RBOdqAbGKzsQ=.a2118233-3311-49b9-acaf-c4241091d928@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
 <1jA_lH7-3g7zTrXOZIP4LnTjVWrHX80RBOdqAbGKzsQ=.a2118233-3311-49b9-acaf-c4241091d928@github.com>
Message-ID: <4bzCgX1KLhuApHrpGtMLeqBXyiywwiJVtz1m0e8RF10=.e714dcdf-98bb-4934-8ac8-27c407f0b4c4@github.com>

On Fri, 23 Jun 2023 02:43:38 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Merge branch 'openjdk:master' into patch-6
>  - Whitespace
>  - Revert
>  - _MSC_VER
>  - Restore visCPP
>  - Restore gcc attribute
>  - Revert gcc
>  - Revert
>  - Semicolon
>  - gcc offset_of
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/5a82fa3b...6c289fb3

Marked as reviewed by mdoerr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13258#pullrequestreview-1497130480

From dholmes at openjdk.org  Mon Jun 26 00:35:18 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 26 Jun 2023 00:35:18 GMT
Subject: RFR: 8305341: Alignment should be enforced by alignas instead of
 compiler specific attributes [v6]
In-Reply-To: <4byEsN8A77TyPs1uUYoCajUiOUy54KE1TRl_PeQG7MA=.3ead4dde-1553-4499-adc0-9a2ba6d53022@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
 <1jA_lH7-3g7zTrXOZIP4LnTjVWrHX80RBOdqAbGKzsQ=.a2118233-3311-49b9-acaf-c4241091d928@github.com>
 <4byEsN8A77TyPs1uUYoCajUiOUy54KE1TRl_PeQG7MA=.3ead4dde-1553-4499-adc0-9a2ba6d53022@github.com>
Message-ID: <p_dBY8Ae1WxhGzhecNFJt_ZqAjqRDXaXOsjfWaf7L6o=.ef745d47-9310-41d0-a0aa-d3f78bf4bc72@github.com>

On Sun, 25 Jun 2023 15:58:06 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
>> 
>>  - Merge branch 'openjdk:master' into patch-6
>>  - Whitespace
>>  - Revert
>>  - _MSC_VER
>>  - Restore visCPP
>>  - Restore gcc attribute
>>  - Revert gcc
>>  - Revert
>>  - Semicolon
>>  - gcc offset_of
>>  - ... and 8 more: https://git.openjdk.org/jdk/compare/5a82fa3b...6c289fb3
>
> Bumping

@TheShermanTanker  this is causing build failures in our CI in tier1:

 c:\sb\prod\1687737602\workspace\open\src\jdk.jdwp.agent\share\native\libjdwp\ArrayReferenceImpl.c(26): fatal error C1083: Cannot open include file: 'stdalign.h': No such file or directory

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

PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1606360752

From jwaters at openjdk.org  Mon Jun 26 00:35:18 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 26 Jun 2023 00:35:18 GMT
Subject: Integrated: 8305341: Alignment should be enforced by alignas instead
 of compiler specific attributes
In-Reply-To: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
Message-ID: <UqgCujJEUXTyx3J7e8Ke9FGudpp1ZlW_o93Up74yNoo=.b5e64a90-3819-4514-aa9d-576b55024a10@github.com>

On Fri, 31 Mar 2023 06:07:39 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements

This pull request has now been integrated.

Changeset: 78c38317
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/78c3831701667069e7e048cd56b534ae2d8d15a1
Stats:     11 lines in 3 files changed: 5 ins; 0 del; 6 mod

8305341: Alignment should be enforced by alignas instead of compiler specific attributes

Reviewed-by: mdoerr

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

PR: https://git.openjdk.org/jdk/pull/13258

From dholmes at openjdk.org  Mon Jun 26 00:40:21 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 26 Jun 2023 00:40:21 GMT
Subject: RFR: 8305341: Alignment should be enforced by alignas instead of
 compiler specific attributes [v6]
In-Reply-To: <1jA_lH7-3g7zTrXOZIP4LnTjVWrHX80RBOdqAbGKzsQ=.a2118233-3311-49b9-acaf-c4241091d928@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
 <1jA_lH7-3g7zTrXOZIP4LnTjVWrHX80RBOdqAbGKzsQ=.a2118233-3311-49b9-acaf-c4241091d928@github.com>
Message-ID: <lhL7RF6SKE6ROGAZqUMto-zB60CZ_6Wl42dTBg0zq0Y=.2568f0db-57d0-4bc8-8bf7-cf6b972946e6@github.com>

On Fri, 23 Jun 2023 02:43:38 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Merge branch 'openjdk:master' into patch-6
>  - Whitespace
>  - Revert
>  - _MSC_VER
>  - Restore visCPP
>  - Restore gcc attribute
>  - Revert gcc
>  - Revert
>  - Semicolon
>  - gcc offset_of
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/5a82fa3b...6c289fb3

Filed: [JDK-8310863](https://bugs.openjdk.org/browse/JDK-8310863)

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

PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1606362416

From jwaters at openjdk.org  Mon Jun 26 02:38:02 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 26 Jun 2023 02:38:02 GMT
Subject: RFR: 8310863: Build failure after  JDK- 8305341
Message-ID: <cYY8Uuwfk3tBv-V6yLmnbGR95dO_sTz5nrUSUSh1_qU=.8f29cdf5-bf36-4e41-aa50-ef9708ee5ef6@github.com>

Microsoft, your C "conformance" is garbage

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

Commit messages:
 - ArrayReferenceImpl.c
 - GSSLibStub.c
 - 8310863

Changes: https://git.openjdk.org/jdk/pull/14645/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14645&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310863
  Stats: 11 lines in 3 files changed: 0 ins; 5 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/14645.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14645/head:pull/14645

PR: https://git.openjdk.org/jdk/pull/14645

From jwaters at openjdk.org  Mon Jun 26 02:41:02 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 26 Jun 2023 02:41:02 GMT
Subject: RFR: 8310863: Build failure after  JDK- 8305341
In-Reply-To: <cYY8Uuwfk3tBv-V6yLmnbGR95dO_sTz5nrUSUSh1_qU=.8f29cdf5-bf36-4e41-aa50-ef9708ee5ef6@github.com>
References: <cYY8Uuwfk3tBv-V6yLmnbGR95dO_sTz5nrUSUSh1_qU=.8f29cdf5-bf36-4e41-aa50-ef9708ee5ef6@github.com>
Message-ID: <sPGNzMkMcmQFZKaOKLdJMOmexX6lLWu5jSJ6XC4U-go=.cefd4a94-429c-4a12-b7fb-8c92c8f8dfe7@github.com>

On Mon, 26 Jun 2023 02:30:06 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Microsoft, your C "conformance" is garbage

@dholmes-ora

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

PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606505881

From dholmes at openjdk.org  Mon Jun 26 04:18:03 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 26 Jun 2023 04:18:03 GMT
Subject: RFR: 8310863: Build failure after  JDK- 8305341
In-Reply-To: <cYY8Uuwfk3tBv-V6yLmnbGR95dO_sTz5nrUSUSh1_qU=.8f29cdf5-bf36-4e41-aa50-ef9708ee5ef6@github.com>
References: <cYY8Uuwfk3tBv-V6yLmnbGR95dO_sTz5nrUSUSh1_qU=.8f29cdf5-bf36-4e41-aa50-ef9708ee5ef6@github.com>
Message-ID: <Hhh_FKw1oIyQz7bUee4GaZ_I1MBB1xby0kYyz5Te3qM=.c4a91f5c-c657-4772-9bdf-09bde30e33ef@github.com>

On Mon, 26 Jun 2023 02:30:06 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Microsoft, your C "conformance" is garbage

https://learn.microsoft.com/en-us/cpp/standard-library/cstdalign?view=msvc-170

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

PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606567568

From jwaters at openjdk.org  Mon Jun 26 04:27:01 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 26 Jun 2023 04:27:01 GMT
Subject: RFR: 8310863: Build failure after  JDK- 8305341
In-Reply-To: <Hhh_FKw1oIyQz7bUee4GaZ_I1MBB1xby0kYyz5Te3qM=.c4a91f5c-c657-4772-9bdf-09bde30e33ef@github.com>
References: <cYY8Uuwfk3tBv-V6yLmnbGR95dO_sTz5nrUSUSh1_qU=.8f29cdf5-bf36-4e41-aa50-ef9708ee5ef6@github.com>
 <Hhh_FKw1oIyQz7bUee4GaZ_I1MBB1xby0kYyz5Te3qM=.c4a91f5c-c657-4772-9bdf-09bde30e33ef@github.com>
Message-ID: <mjrECmZvjknMqmDBuNiqUiLRAgMBolMo1j_YiMX6ysw=.40515440-f698-4377-8579-1a1ae9942b65@github.com>

On Mon, 26 Jun 2023 04:15:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

> https://learn.microsoft.com/en-us/cpp/standard-library/cstdalign?view=msvc-170

:/

> How was the original change tested? How was this change tested?

I made the mistake of testing the original on gcc instead of the native compiler for Windows, I recompiled this one with the microsoft toolchain before writing the fix, which fortunately passes the compile step as is evident in the tests for this PR

Sorry for the goof :(

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

PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606570640
PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606572218

From jwaters at openjdk.org  Mon Jun 26 04:27:03 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 26 Jun 2023 04:27:03 GMT
Subject: RFR: 8310863: Build failure after  JDK- 8305341
In-Reply-To: <cYY8Uuwfk3tBv-V6yLmnbGR95dO_sTz5nrUSUSh1_qU=.8f29cdf5-bf36-4e41-aa50-ef9708ee5ef6@github.com>
References: <cYY8Uuwfk3tBv-V6yLmnbGR95dO_sTz5nrUSUSh1_qU=.8f29cdf5-bf36-4e41-aa50-ef9708ee5ef6@github.com>
Message-ID: <gIfm8qZ2FsA7vWIyk33EByUzYQ6Fw-x44H2JMZWwuBE=.da6757dc-7554-4eb9-abb9-a7324584c5a2@github.com>

On Mon, 26 Jun 2023 02:30:06 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Build failure after JDK- 8305341

_Alignas does work on Microsoft Visual C, fortunately

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

PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606570803

From dholmes at openjdk.org  Mon Jun 26 04:27:03 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 26 Jun 2023 04:27:03 GMT
Subject: RFR: 8310863: Build failure after  JDK- 8305341
In-Reply-To: <cYY8Uuwfk3tBv-V6yLmnbGR95dO_sTz5nrUSUSh1_qU=.8f29cdf5-bf36-4e41-aa50-ef9708ee5ef6@github.com>
References: <cYY8Uuwfk3tBv-V6yLmnbGR95dO_sTz5nrUSUSh1_qU=.8f29cdf5-bf36-4e41-aa50-ef9708ee5ef6@github.com>
Message-ID: <ieVDNTDPPmqOp5p9LGSKXLJo9UCaASLclqfI7K-FfkQ=.c0c1548a-a301-4681-a765-fd71d15ac9d6@github.com>

On Mon, 26 Jun 2023 02:30:06 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Build failure after JDK- 8305341

How was the original change tested? How was this change tested?

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

PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606571300

From dholmes at openjdk.org  Mon Jun 26 04:30:07 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 26 Jun 2023 04:30:07 GMT
Subject: RFR: 8310863: Build failure after  JDK- 8305341
In-Reply-To: <mjrECmZvjknMqmDBuNiqUiLRAgMBolMo1j_YiMX6ysw=.40515440-f698-4377-8579-1a1ae9942b65@github.com>
References: <cYY8Uuwfk3tBv-V6yLmnbGR95dO_sTz5nrUSUSh1_qU=.8f29cdf5-bf36-4e41-aa50-ef9708ee5ef6@github.com>
 <Hhh_FKw1oIyQz7bUee4GaZ_I1MBB1xby0kYyz5Te3qM=.c4a91f5c-c657-4772-9bdf-09bde30e33ef@github.com>
 <mjrECmZvjknMqmDBuNiqUiLRAgMBolMo1j_YiMX6ysw=.40515440-f698-4377-8579-1a1ae9942b65@github.com>
Message-ID: <fF9PMyjiDtj0uYFyHPpO584H_yVNacE4k300-EZUef8=.bcd6b4cf-9284-4f73-8dc8-190fca8e3e21@github.com>

On Mon, 26 Jun 2023 04:23:58 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> as is evident in the tests for this PR

You mean the GHA builds? They don't seem to be building the failing `jdk.jdwp.agent-static-libs` target.

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

PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606573575

From jwaters at openjdk.org  Mon Jun 26 04:41:02 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 26 Jun 2023 04:41:02 GMT
Subject: RFR: 8310863: Build failure after  JDK- 8305341
In-Reply-To: <fF9PMyjiDtj0uYFyHPpO584H_yVNacE4k300-EZUef8=.bcd6b4cf-9284-4f73-8dc8-190fca8e3e21@github.com>
References: <cYY8Uuwfk3tBv-V6yLmnbGR95dO_sTz5nrUSUSh1_qU=.8f29cdf5-bf36-4e41-aa50-ef9708ee5ef6@github.com>
 <Hhh_FKw1oIyQz7bUee4GaZ_I1MBB1xby0kYyz5Te3qM=.c4a91f5c-c657-4772-9bdf-09bde30e33ef@github.com>
 <mjrECmZvjknMqmDBuNiqUiLRAgMBolMo1j_YiMX6ysw=.40515440-f698-4377-8579-1a1ae9942b65@github.com>
 <fF9PMyjiDtj0uYFyHPpO584H_yVNacE4k300-EZUef8=.bcd6b4cf-9284-4f73-8dc8-190fca8e3e21@github.com>
Message-ID: <h9OrsAqvs6OYNLkpnAu45lb8uZ-eY1Dk9GetYUp0v9o=.0b228d52-f784-4ad5-9a05-51c6833c0c0a@github.com>

On Mon, 26 Jun 2023 04:26:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > as is evident in the tests for this PR
> 
> You mean the GHA builds? They don't seem to be building the failing `jdk.jdwp.agent-static-libs` target.

I can't recompile the JDK at the moment to compile ArrayReferenceImpl.c, but I can devise a simple test for this:


#include <stdio.h>

int main() {
    _Alignas(8)
    int i = 7;
    printf("%i", i);
    return 0;
}


`cl.exe -nologo -std:c11 -Fo:align.o align.c`


align.exe
7


The _Alignas specifier does the same thing as the __declspec(align()) one, so there's no difference in which is used (which also means that the other places where this is used being able to compile is proof of it working as well)

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

PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606579037

From dholmes at openjdk.org  Mon Jun 26 04:41:03 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 26 Jun 2023 04:41:03 GMT
Subject: RFR: 8310863: Build failure after  JDK- 8305341
In-Reply-To: <cYY8Uuwfk3tBv-V6yLmnbGR95dO_sTz5nrUSUSh1_qU=.8f29cdf5-bf36-4e41-aa50-ef9708ee5ef6@github.com>
References: <cYY8Uuwfk3tBv-V6yLmnbGR95dO_sTz5nrUSUSh1_qU=.8f29cdf5-bf36-4e41-aa50-ef9708ee5ef6@github.com>
Message-ID: <GcoRdVwL-m1RqrVHwpFCTXgENFSa_I6Yyj5Fq9h3yBc=.f950417d-92e6-47dc-b08b-8d6b1fce25f2@github.com>

On Mon, 26 Jun 2023 02:30:06 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Build failure after JDK- 8305341

Okay I have it running through our tier1 builds at the moment. If that passes I will approve the PR. Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/14645#issuecomment-1606580347

From cjplummer at openjdk.org  Mon Jun 26 05:09:05 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 26 Jun 2023 05:09:05 GMT
Subject: RFR: 8294316: SA core file support is broken on macosx-x64
 starting with macOS 12.x [v2]
In-Reply-To: <tJvVPDUTdKDLNHtqCbkuHrnLxlOfWaXuizfoGXE5NHo=.5983a878-e421-41bc-a0af-fb6f8d9a98da@github.com>
References: <0wPtkRqjB3Nh6LiABARFcqq6UqcCsTNbF1ok1iG0Efw=.af55940f-5b2d-4cfb-b233-066a419bae48@github.com>
 <tJvVPDUTdKDLNHtqCbkuHrnLxlOfWaXuizfoGXE5NHo=.5983a878-e421-41bc-a0af-fb6f8d9a98da@github.com>
Message-ID: <zbCVYQlM1zAihoBqarrDU403LRJFJL1DhsSYnKm7iCU=.44dc4d51-14b3-47c4-9836-ab0616aa1128@github.com>

On Fri, 23 Jun 2023 19:31:20 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> This is a minor fix to core file reading on macos x.  I can confirm that after this fix I can run the problem listed SA core file tests on Ventura.
>
> Tom Rodriguez has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Flatten nested ifs
>  - Adjust ordering of message
>  - Adjust printing

src/jdk.hotspot.agent/macosx/native/libsaproc/ps_core.c line 302:

> 300:       // The base of the library is offset by a random amount which ends up as a load command with a
> 301:       // filesize of 0.  This must be ignored otherwise the base address of the library is wrong.
> 302:       if (segcmd.filesize != 0 && add_map_info(ph, fd, segcmd.fileoff, segcmd.vmaddr, segcmd.vmsize, segcmd.flags) == NULL) {

I actually preferred this part with  two `if` statements. Seems easier to read that way.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14569#discussion_r1241570338

From cjplummer at openjdk.org  Mon Jun 26 05:14:03 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 26 Jun 2023 05:14:03 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work [v3]
In-Reply-To: <y6e_N1LMrTBZdZekhjzGj2KwcMhVO-qFNgnUXudcgE8=.20369c56-290f-4f8c-ae2e-a2399fcde214@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
 <LdyQw-4zZwjHIW1MC9q43Nekj30shwvyJBaNbPsLg54=.bb966145-68be-4e46-89a5-12c1f0b9048e@github.com>
 <y6e_N1LMrTBZdZekhjzGj2KwcMhVO-qFNgnUXudcgE8=.20369c56-290f-4f8c-ae2e-a2399fcde214@github.com>
Message-ID: <XFE3cHwoEO7y4dB1gKsSXxFoR7clRga_op-MvwUFbfE=.26f21c73-1ff1-488a-88e8-34fafbfb3bfb@github.com>

On Fri, 23 Jun 2023 08:37:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Chris are you okay with the latest rev. of this change?

Sorry, I've been on vacation the past few days. I will have a look at it tomorrow.

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

PR Comment: https://git.openjdk.org/jdk/pull/14562#issuecomment-1606661232

From dholmes at openjdk.org  Mon Jun 26 05:30:10 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 26 Jun 2023 05:30:10 GMT
Subject: RFR: 8310863: Build failure after  JDK- 8305341
In-Reply-To: <cYY8Uuwfk3tBv-V6yLmnbGR95dO_sTz5nrUSUSh1_qU=.8f29cdf5-bf36-4e41-aa50-ef9708ee5ef6@github.com>
References: <cYY8Uuwfk3tBv-V6yLmnbGR95dO_sTz5nrUSUSh1_qU=.8f29cdf5-bf36-4e41-aa50-ef9708ee5ef6@github.com>
Message-ID: <JP0QBb6B31vaJbtU67lM3LQTpdkEkbLYuxgFB7YEKbU=.e2aa89c0-6deb-4db1-863f-d714970d249e@github.com>

On Mon, 26 Jun 2023 02:30:06 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Build failure after JDK- 8305341

Our tier 1 builds have passed.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14645#pullrequestreview-1497595990

From jwaters at openjdk.org  Mon Jun 26 05:41:09 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 26 Jun 2023 05:41:09 GMT
Subject: Integrated: 8310863: Build failure after  JDK- 8305341
In-Reply-To: <cYY8Uuwfk3tBv-V6yLmnbGR95dO_sTz5nrUSUSh1_qU=.8f29cdf5-bf36-4e41-aa50-ef9708ee5ef6@github.com>
References: <cYY8Uuwfk3tBv-V6yLmnbGR95dO_sTz5nrUSUSh1_qU=.8f29cdf5-bf36-4e41-aa50-ef9708ee5ef6@github.com>
Message-ID: <1sF7T0TaWs_9uqjxf3c0f1P6LAvg9ONJjMnPvhy1wR8=.f8a77de2-f674-4733-8be3-b43bf66e6a4f@github.com>

On Mon, 26 Jun 2023 02:30:06 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Build failure after JDK- 8305341

This pull request has now been integrated.

Changeset: 8242c647
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8242c647b9d31320757363b69e7048a109ce86df
Stats:     11 lines in 3 files changed: 0 ins; 5 del; 6 mod

8310863: Build failure after  JDK- 8305341

Reviewed-by: dholmes

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

PR: https://git.openjdk.org/jdk/pull/14645

From dholmes at openjdk.org  Mon Jun 26 07:49:02 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 26 Jun 2023 07:49:02 GMT
Subject: RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit
In-Reply-To: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
References: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
Message-ID: <iWmku3kYvyGToSo-1zcSwnlquou7WJmhW8esd3sWMNs=.7dae028e-bdcd-4648-95d0-a317fe120fc3@github.com>

On Sun, 25 Jun 2023 06:58:14 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> The VMSupport class is required for translating an exception between the HotSpot and libgraal heaps.
> Loading it lazily can result in a loading exception, obscuring the exception being translated.
> To avoid this, VMSupport is loaded eagerly along with the other vmClasses.

The eager loading seems reasonable, but I do not understand the details here. In what way was loading failing? You still have to initialize `VMSupport` before you can call methods on it, so that could also fail - though the code does not seem to notice/handle this. ??

src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 585:

> 583: 
> 584:   if (class_name->utf8_length() <= 1) {
> 585:     JVMCI_THROW_MSG_0(InternalError, err_msg("Primitive type %s should be handled in Java code", str));

Seems unrelated to the fix at hand.

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

PR Review: https://git.openjdk.org/jdk/pull/14641#pullrequestreview-1497840467
PR Review Comment: https://git.openjdk.org/jdk/pull/14641#discussion_r1241749015

From dnsimon at openjdk.org  Mon Jun 26 07:49:03 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 26 Jun 2023 07:49:03 GMT
Subject: RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit
In-Reply-To: <iWmku3kYvyGToSo-1zcSwnlquou7WJmhW8esd3sWMNs=.7dae028e-bdcd-4648-95d0-a317fe120fc3@github.com>
References: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
 <iWmku3kYvyGToSo-1zcSwnlquou7WJmhW8esd3sWMNs=.7dae028e-bdcd-4648-95d0-a317fe120fc3@github.com>
Message-ID: <JAdzgg08g0qgkxQ8mIAsScvqmlzvFk09nB5qYgWYJKo=.2ae11d6e-f997-4dbc-9302-7bd5728db458@github.com>

On Mon, 26 Jun 2023 07:42:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The eager loading seems reasonable, but I do not understand the details here. In what way was loading failing? You still have to initialize `VMSupport` before you can call methods on it, so that could also fail - though the code does not seem to notice/handle this. ??

The usages of `vmSupport` below all use `JavaCalls:call_static` which takes care of linking and initializing the class.

> src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 585:
> 
>> 583: 
>> 584:   if (class_name->utf8_length() <= 1) {
>> 585:     JVMCI_THROW_MSG_0(InternalError, err_msg("Primitive type %s should be handled in Java code", str));
> 
> Seems unrelated to the fix at hand.

Yes, it's a minor fix up I noticed while making changes a few lines below. It just avoids a conversion of a `Symbol` back to a C string when the original C string is available.

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

PR Comment: https://git.openjdk.org/jdk/pull/14641#issuecomment-1606899412
PR Review Comment: https://git.openjdk.org/jdk/pull/14641#discussion_r1241766196

From dholmes at openjdk.org  Mon Jun 26 08:02:03 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 26 Jun 2023 08:02:03 GMT
Subject: RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit
In-Reply-To: <JAdzgg08g0qgkxQ8mIAsScvqmlzvFk09nB5qYgWYJKo=.2ae11d6e-f997-4dbc-9302-7bd5728db458@github.com>
References: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
 <iWmku3kYvyGToSo-1zcSwnlquou7WJmhW8esd3sWMNs=.7dae028e-bdcd-4648-95d0-a317fe120fc3@github.com>
 <JAdzgg08g0qgkxQ8mIAsScvqmlzvFk09nB5qYgWYJKo=.2ae11d6e-f997-4dbc-9302-7bd5728db458@github.com>
Message-ID: <8INVPbgTqA0Enqhog345Mxy44ZY6FCEkD_1NBotu9Mw=.59e217be-f65d-467a-8fed-f95288e1a162@github.com>

On Mon, 26 Jun 2023 07:46:38 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> The usages of `vmSupport` below all use `JavaCalls:call_static` which takes care of linking and initializing the class.

Sure but my point is that initialization can fail and the code does not seem to directly take that into account - if the first `decode` encounters a class initialization error then it will just return with the exception pending and no decoding will actually have occurred. If we get to the `encode` first and it encounters an initialization error it will still attempt to do a `decode` that must in turn fail and again we return with an exception pending and no encoding/decoding occurring. This code does not seem to be written in a  way that allows for an error initializing `VMSupport`. So while the fix side-steps the problematic guarantee, I think it is just highlighting that this code is prepared for "system" errors like this.

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

PR Comment: https://git.openjdk.org/jdk/pull/14641#issuecomment-1606915981

From dholmes at openjdk.org  Mon Jun 26 08:05:03 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 26 Jun 2023 08:05:03 GMT
Subject: RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit
In-Reply-To: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
References: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
Message-ID: <YqcCd7eHahJIowXSCirrRGfcNFbnxVU0ColXiiJ3kPs=.6c9c557a-ad72-4687-9067-bc9202fc62d1@github.com>

On Sun, 25 Jun 2023 06:58:14 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> The VMSupport class is required for translating an exception between the HotSpot and libgraal heaps.
> Loading it lazily can result in a loading exception, obscuring the exception being translated.
> To avoid this, VMSupport is loaded eagerly along with the other vmClasses.

Edited above to correct: I think it is just highlighting that this code **not** is prepared for "system" errors like this.

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

PR Comment: https://git.openjdk.org/jdk/pull/14641#issuecomment-1606923008

From kevinw at openjdk.org  Mon Jun 26 08:38:13 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 26 Jun 2023 08:38:13 GMT
Subject: Integrated: 8310816: GcInfoBuilder float/double signature mismatch
In-Reply-To: <51x6x8swNwXsWnSxuskzLe3sF2x8Ke8rUmVA9pJXPBM=.868ffcd7-652a-4bff-9246-6c6e21f785d3@github.com>
References: <51x6x8swNwXsWnSxuskzLe3sF2x8Ke8rUmVA9pJXPBM=.868ffcd7-652a-4bff-9246-6c6e21f785d3@github.com>
Message-ID: <qYWI_qAoAx3sknvbW-PrEFLy5Mr6a8G8HUjYi8eTV4o=.2c12f15d-dc7b-46f1-a368-6c77fb125894@github.com>

On Fri, 23 Jun 2023 18:10:59 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Simple typo in a signature which is passed to JNU_NewObjectByName.  The method clearly intentds to pass Float, but uses Double.
> 
> This code is probably not invoked, unless there is a GC MXBean with such fields.  I see no straightforward way of testing this explicitly, but the change is tiny.
> 
> All tests in test/jdk/com/sun/management still pass.

This pull request has now been integrated.

Changeset: a96e92c8
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a96e92c83dd3cb36c10282724466e6d1339f58f6
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8310816: GcInfoBuilder float/double signature mismatch

Reviewed-by: mchung, dholmes

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

PR: https://git.openjdk.org/jdk/pull/14631

From kevinw at openjdk.org  Mon Jun 26 08:38:12 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 26 Jun 2023 08:38:12 GMT
Subject: RFR: 8310816: GcInfoBuilder float/double signature mismatch
In-Reply-To: <51x6x8swNwXsWnSxuskzLe3sF2x8Ke8rUmVA9pJXPBM=.868ffcd7-652a-4bff-9246-6c6e21f785d3@github.com>
References: <51x6x8swNwXsWnSxuskzLe3sF2x8Ke8rUmVA9pJXPBM=.868ffcd7-652a-4bff-9246-6c6e21f785d3@github.com>
Message-ID: <mk9w851HP-ezesEGySpKywqVCkOeyRX8sUV49YDtbME=.2d3851ec-d0fb-4099-b469-2604090232c6@github.com>

On Fri, 23 Jun 2023 18:10:59 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Simple typo in a signature which is passed to JNU_NewObjectByName.  The method clearly intentds to pass Float, but uses Double.
> 
> This code is probably not invoked, unless there is a GC MXBean with such fields.  I see no straightforward way of testing this explicitly, but the change is tiny.
> 
> All tests in test/jdk/com/sun/management still pass.

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/14631#issuecomment-1606975619

From erikj at openjdk.org  Mon Jun 26 09:32:19 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 26 Jun 2023 09:32:19 GMT
Subject: RFR: 8298047: Remove all non-significant trailing whitespace from
 properties files [v2]
In-Reply-To: <_N1D3JRNf6qFNvV8d2XZMdDWO7BC8pk58CR7fVNTDcM=.bad91d00-fd4e-4a16-a9fc-f274d38f213d@github.com>
References: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
 <X1UfghRlNyAzyQCMfM6r9kApI-YH6bAcjUPh8Gha8ZI=.79477f8e-2278-4f1b-904f-a091841dcd5b@github.com>
 <_N1D3JRNf6qFNvV8d2XZMdDWO7BC8pk58CR7fVNTDcM=.bad91d00-fd4e-4a16-a9fc-f274d38f213d@github.com>
Message-ID: <G2HH46a1taYMgOcec5NyuO8VdM0f22Km2LRV5HkEAqg=.dd217011-3a2d-4357-ba0e-bf46f725822a@github.com>

On Sat, 24 Jun 2023 06:47:48 GMT, Vladimir Sitnikov <vsitnikov at openjdk.org> wrote:

> I've posted the suggetion to add .editorconfig on ide-support-dev, however, the list does not seem to be active: https://mail.openjdk.org/pipermail/ide-support-dev/2023-June/000281.html

I think that sounds like a reasonable idea. I'm not following that mailing list. I think you can just post a PR with your suggested contents and target build-dev (through the `build` label). I'm not familiar with this kind of file, so an explanation of which IDEs support it would be good to include.

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

PR Comment: https://git.openjdk.org/jdk/pull/11491#issuecomment-1607073914

From dnsimon at openjdk.org  Mon Jun 26 13:03:27 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 26 Jun 2023 13:03:27 GMT
Subject: RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit [v2]
In-Reply-To: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
References: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
Message-ID: <EG_-SGuOauw2Kjp-caeyw8XwNg6n-OahdDFihUeb4hc=.7ece8b58-3792-44eb-941a-559c4b9259e3@github.com>

> The VMSupport class is required for translating an exception between the HotSpot and libgraal heaps.
> Loading it lazily can result in a loading exception, obscuring the exception being translated.
> To avoid this, VMSupport is loaded eagerly along with the other vmClasses.

Doug Simon has updated the pull request incrementally with one additional commit since the last revision:

  try harder to show nested exception during exception translation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14641/files
  - new: https://git.openjdk.org/jdk/pull/14641/files/fafc0aae..614e1e9f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14641&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14641&range=00-01

  Stats: 51 lines in 4 files changed: 21 ins; 4 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/14641.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14641/head:pull/14641

PR: https://git.openjdk.org/jdk/pull/14641

From dnsimon at openjdk.org  Mon Jun 26 13:10:05 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 26 Jun 2023 13:10:05 GMT
Subject: RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit [v2]
In-Reply-To: <8INVPbgTqA0Enqhog345Mxy44ZY6FCEkD_1NBotu9Mw=.59e217be-f65d-467a-8fed-f95288e1a162@github.com>
References: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
 <iWmku3kYvyGToSo-1zcSwnlquou7WJmhW8esd3sWMNs=.7dae028e-bdcd-4648-95d0-a317fe120fc3@github.com>
 <JAdzgg08g0qgkxQ8mIAsScvqmlzvFk09nB5qYgWYJKo=.2ae11d6e-f997-4dbc-9302-7bd5728db458@github.com>
 <8INVPbgTqA0Enqhog345Mxy44ZY6FCEkD_1NBotu9Mw=.59e217be-f65d-467a-8fed-f95288e1a162@github.com>
Message-ID: <40ibXO2G3peem2lojRZ085yBDzKq3Dlha-RjJTkn9r8=.3be3d6d7-9e8a-4f3c-bcce-d03d63e3dc2b@github.com>

On Mon, 26 Jun 2023 07:59:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

> if the first decode encounters a class initialization error then it will just return with the exception pending and no decoding will actually have occurred

That's fine - if VMSupport fails class initialization, then no "rich" decoding can occur (by definition) and so throwing the clinit error is the best we can do.

> If we get to the encode first and it encounters an initialization error it will still attempt to do a decode that must in turn fail 

You have to keep in mind that `encode` and `decode` are called in different runtimes. If encoding an exception in the HotSpot runtime fails (e.g. due to an OOME calling `VMSupport.<clinit>` in the HotSpot heap), then it's still fine to try call `VMSupport.decode` in the libgraal runtime. If `VMSupport.decode` in the libgraal runtime also fails, then it throw the exception describing the secondary failure. There's simply no way to guarantee all info is shown when secondary issues occur during exception handling.

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

PR Comment: https://git.openjdk.org/jdk/pull/14641#issuecomment-1607433634

From dnsimon at openjdk.org  Mon Jun 26 13:17:25 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 26 Jun 2023 13:17:25 GMT
Subject: RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit [v3]
In-Reply-To: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
References: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
Message-ID: <bY4wAhAD6sOLr0zuHQJ6tMkD6shiL4RwnL7kIxk91YI=.03848181-fa09-4988-bd9d-7d0dc4e85d49@github.com>

> The VMSupport class is required for translating an exception between the HotSpot and libgraal heaps.
> Loading it lazily can result in a loading exception, obscuring the exception being translated.
> To avoid this, VMSupport is loaded eagerly along with the other vmClasses.

Doug Simon has updated the pull request incrementally with one additional commit since the last revision:

  each exception translation failure should trigger a JVMCI event

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14641/files
  - new: https://git.openjdk.org/jdk/pull/14641/files/614e1e9f..819a24fd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14641&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14641&range=01-02

  Stats: 4 lines in 2 files changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14641.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14641/head:pull/14641

PR: https://git.openjdk.org/jdk/pull/14641

From dnsimon at openjdk.org  Mon Jun 26 13:25:07 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 26 Jun 2023 13:25:07 GMT
Subject: RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit [v3]
In-Reply-To: <bY4wAhAD6sOLr0zuHQJ6tMkD6shiL4RwnL7kIxk91YI=.03848181-fa09-4988-bd9d-7d0dc4e85d49@github.com>
References: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
 <bY4wAhAD6sOLr0zuHQJ6tMkD6shiL4RwnL7kIxk91YI=.03848181-fa09-4988-bd9d-7d0dc4e85d49@github.com>
Message-ID: <fEhhdigD508J6nVAlhRDaLUvHzTN_-WUNSdlaI-Ibqo=.cae3c5e0-2144-42b2-a56b-c195f83c01ad@github.com>

On Mon, 26 Jun 2023 13:17:25 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> The VMSupport class is required for translating an exception between the HotSpot and libgraal heaps.
>> Loading it lazily can result in a loading exception, obscuring the exception being translated.
>> To avoid this, VMSupport is loaded eagerly along with the other vmClasses.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   each exception translation failure should trigger a JVMCI event

BTW, I've manually tested this with libgraal. It's not possible to add a jtreg test until libgraal in part of OpenJDK.

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

PR Comment: https://git.openjdk.org/jdk/pull/14641#issuecomment-1607466267

From never at openjdk.org  Mon Jun 26 16:46:05 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Mon, 26 Jun 2023 16:46:05 GMT
Subject: RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit [v3]
In-Reply-To: <bY4wAhAD6sOLr0zuHQJ6tMkD6shiL4RwnL7kIxk91YI=.03848181-fa09-4988-bd9d-7d0dc4e85d49@github.com>
References: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
 <bY4wAhAD6sOLr0zuHQJ6tMkD6shiL4RwnL7kIxk91YI=.03848181-fa09-4988-bd9d-7d0dc4e85d49@github.com>
Message-ID: <QZgY4zQIAiHZBhjqv-QFfEy-bNcMxDtgeocHIdbgbxg=.48b9ba06-68b8-49e0-9e4a-a04bab8b30e3@github.com>

On Mon, 26 Jun 2023 13:17:25 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> The VMSupport class is required for translating an exception between the HotSpot and libgraal heaps.
>> Loading it lazily can result in a loading exception, obscuring the exception being translated.
>> To avoid this, VMSupport is loaded eagerly along with the other vmClasses.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   each exception translation failure should trigger a JVMCI event

looks ok to me.

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

Marked as reviewed by never (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14641#pullrequestreview-1498967746

From never at openjdk.org  Mon Jun 26 17:02:22 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Mon, 26 Jun 2023 17:02:22 GMT
Subject: RFR: 8294316: SA core file support is broken on macosx-x64
 starting with macOS 12.x [v3]
In-Reply-To: <0wPtkRqjB3Nh6LiABARFcqq6UqcCsTNbF1ok1iG0Efw=.af55940f-5b2d-4cfb-b233-066a419bae48@github.com>
References: <0wPtkRqjB3Nh6LiABARFcqq6UqcCsTNbF1ok1iG0Efw=.af55940f-5b2d-4cfb-b233-066a419bae48@github.com>
Message-ID: <FL_ef7Ep2UVlWFmZ_tjRqXVmEbXN3Im71rzbzM2Ls3A=.0e6c37ac-26be-4568-a2b0-e3a269c2e396@github.com>

> This is a minor fix to core file reading on macos x.  I can confirm that after this fix I can run the problem listed SA core file tests on Ventura.

Tom Rodriguez has updated the pull request incrementally with one additional commit since the last revision:

  Adjust for review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14569/files
  - new: https://git.openjdk.org/jdk/pull/14569/files/2ebe4d09..bd45a311

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14569&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14569&range=01-02

  Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14569.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14569/head:pull/14569

PR: https://git.openjdk.org/jdk/pull/14569

From never at openjdk.org  Mon Jun 26 17:02:24 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Mon, 26 Jun 2023 17:02:24 GMT
Subject: RFR: 8294316: SA core file support is broken on macosx-x64
 starting with macOS 12.x [v2]
In-Reply-To: <zbCVYQlM1zAihoBqarrDU403LRJFJL1DhsSYnKm7iCU=.44dc4d51-14b3-47c4-9836-ab0616aa1128@github.com>
References: <0wPtkRqjB3Nh6LiABARFcqq6UqcCsTNbF1ok1iG0Efw=.af55940f-5b2d-4cfb-b233-066a419bae48@github.com>
 <tJvVPDUTdKDLNHtqCbkuHrnLxlOfWaXuizfoGXE5NHo=.5983a878-e421-41bc-a0af-fb6f8d9a98da@github.com>
 <zbCVYQlM1zAihoBqarrDU403LRJFJL1DhsSYnKm7iCU=.44dc4d51-14b3-47c4-9836-ab0616aa1128@github.com>
Message-ID: <_50bEOswIL_FxOBxHpu72-w_mSotyhB4Il8d05sEh70=.8d0373f2-1399-498d-a016-ca1129bdc023@github.com>

On Mon, 26 Jun 2023 05:06:13 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Tom Rodriguez has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Flatten nested ifs
>>  - Adjust ordering of message
>>  - Adjust printing
>
> src/jdk.hotspot.agent/macosx/native/libsaproc/ps_core.c line 302:
> 
>> 300:       // The base of the library is offset by a random amount which ends up as a load command with a
>> 301:       // filesize of 0.  This must be ignored otherwise the base address of the library is wrong.
>> 302:       if (segcmd.filesize != 0 && add_map_info(ph, fd, segcmd.fileoff, segcmd.vmaddr, segcmd.vmsize, segcmd.flags) == NULL) {
> 
> I actually preferred this part with  two `if` statements. Seems easier to read that way.

Ok.  I reverted it to 2 ifs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14569#discussion_r1242483550

From cjplummer at openjdk.org  Mon Jun 26 17:12:04 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 26 Jun 2023 17:12:04 GMT
Subject: RFR: 8294316: SA core file support is broken on macosx-x64
 starting with macOS 12.x [v3]
In-Reply-To: <FL_ef7Ep2UVlWFmZ_tjRqXVmEbXN3Im71rzbzM2Ls3A=.0e6c37ac-26be-4568-a2b0-e3a269c2e396@github.com>
References: <0wPtkRqjB3Nh6LiABARFcqq6UqcCsTNbF1ok1iG0Efw=.af55940f-5b2d-4cfb-b233-066a419bae48@github.com>
 <FL_ef7Ep2UVlWFmZ_tjRqXVmEbXN3Im71rzbzM2Ls3A=.0e6c37ac-26be-4568-a2b0-e3a269c2e396@github.com>
Message-ID: <MiZYxtDIGQOKjyQyvM2k_1F-l6EKu4tG7pu61oxDqTg=.9ee544b4-48be-4e77-aba0-fbb4d38f60e0@github.com>

On Mon, 26 Jun 2023 17:02:22 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> This is a minor fix to core file reading on macos x.  I can confirm that after this fix I can run the problem listed SA core file tests on Ventura.
>
> Tom Rodriguez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust for review

Marked as reviewed by cjplummer (Reviewer).

Please update the copyright before integrating.

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

PR Review: https://git.openjdk.org/jdk/pull/14569#pullrequestreview-1499010655
Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14569#pullrequestreview-1499012965

From cjplummer at openjdk.org  Mon Jun 26 17:30:07 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 26 Jun 2023 17:30:07 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work [v3]
In-Reply-To: <LdyQw-4zZwjHIW1MC9q43Nekj30shwvyJBaNbPsLg54=.bb966145-68be-4e46-89a5-12c1f0b9048e@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
 <LdyQw-4zZwjHIW1MC9q43Nekj30shwvyJBaNbPsLg54=.bb966145-68be-4e46-89a5-12c1f0b9048e@github.com>
Message-ID: <_h7vnjrzdStRA3c3IARtSbjUsih9GqMoi72cXMkmzL0=.e2fb94d1-fd87-4d4b-9212-f255f2321477@github.com>

On Thu, 22 Jun 2023 11:51:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
>> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
>> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
>> But without the entitlement, a core is not generated.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move javaPath into caller

Changes requested by cjplummer (Reviewer).

test/lib/jdk/test/lib/Platform.java line 276:

> 274:     }
> 275: 
> 276:     public static boolean hasPlistEntriesOSX() throws IOException {

Although I understand why you chose this API name (it mimics the form used for `isHardenedOSX`), I don't think it is a good choice. `isHardenedOSX` is short for "is this a hardened OSX system". That mapping does not work with `hasPlistEntriesOSX`, which is more like "does this OSX system have plist entries". I would suggest `hasOSXPlistEntries`.

test/lib/jdk/test/lib/util/CoreUtils.java line 154:

> 152:                 }
> 153:             } else {
> 154:                 // codesign has to add entitlements using the plist, if this is not present we might not generate a core file

Suggestion:

                // codesign has to add entitlements using the plist. If this is not present we might not generate a core file.

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

PR Review: https://git.openjdk.org/jdk/pull/14562#pullrequestreview-1499040669
PR Review Comment: https://git.openjdk.org/jdk/pull/14562#discussion_r1242519320
PR Review Comment: https://git.openjdk.org/jdk/pull/14562#discussion_r1242520818

From coleenp at openjdk.org  Mon Jun 26 17:54:14 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 26 Jun 2023 17:54:14 GMT
Subject: RFR: 8310906: Fix -Wconversion warnings in runtime,
 oops and some code header files.
Message-ID: <moXhLb2jOytefh6AdiUqTmvzvZBJrFV3RoJNZ7tLjbM=.39b74dd0-5f33-4cda-929e-7ccb2aaebfc5@github.com>

More casts for size of address differences in same code space, checked_casts<> and type changes to fix -Wconversion warnings.  See CR for details.
Tested with tier1-4.

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

Commit messages:
 - Fix -Wconversion warnings in runtime, oops and some code header files.

Changes: https://git.openjdk.org/jdk/pull/14659/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14659&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310906
  Stats: 71 lines in 36 files changed: 0 ins; 0 del; 71 mod
  Patch: https://git.openjdk.org/jdk/pull/14659.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14659/head:pull/14659

PR: https://git.openjdk.org/jdk/pull/14659

From never at openjdk.org  Mon Jun 26 18:09:24 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Mon, 26 Jun 2023 18:09:24 GMT
Subject: RFR: 8294316: SA core file support is broken on macosx-x64
 starting with macOS 12.x [v4]
In-Reply-To: <0wPtkRqjB3Nh6LiABARFcqq6UqcCsTNbF1ok1iG0Efw=.af55940f-5b2d-4cfb-b233-066a419bae48@github.com>
References: <0wPtkRqjB3Nh6LiABARFcqq6UqcCsTNbF1ok1iG0Efw=.af55940f-5b2d-4cfb-b233-066a419bae48@github.com>
Message-ID: <2vbBaOc6yp_JozXoDxdwwOMK51xxmumzbK-84EEB4HY=.d53a282d-e680-4a76-a1a1-d92a397ae335@github.com>

> This is a minor fix to core file reading on macos x.  I can confirm that after this fix I can run the problem listed SA core file tests on Ventura.

Tom Rodriguez has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14569/files
  - new: https://git.openjdk.org/jdk/pull/14569/files/bd45a311..1eed618c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14569&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14569&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14569.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14569/head:pull/14569

PR: https://git.openjdk.org/jdk/pull/14569

From cjplummer at openjdk.org  Mon Jun 26 18:30:02 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 26 Jun 2023 18:30:02 GMT
Subject: RFR: 8310585: GetThreadState spec mentions undefined
 JVMTI_THREAD_STATE_MONITOR_WAITING
In-Reply-To: <cS0KuoYy8kK2zVNJ733E-oXIAQyVqDuEgKm9RKKxipk=.5e2c01d5-97f8-4df3-a569-e7f5ea127df0@github.com>
References: <cS0KuoYy8kK2zVNJ733E-oXIAQyVqDuEgKm9RKKxipk=.5e2c01d5-97f8-4df3-a569-e7f5ea127df0@github.com>
Message-ID: <Fwv1YrGbidiR5Ni1UNgfZYWO4boU6X9R6peH0knXoGY=.3c7c5622-622e-4973-8d93-b7a981d026df@github.com>

On Fri, 23 Jun 2023 22:59:54 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Trivial fix in JVMTI spec.
> As it's just a typo, CSR is not required

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14634#pullrequestreview-1499146614

From fparain at openjdk.org  Mon Jun 26 20:23:08 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 26 Jun 2023 20:23:08 GMT
Subject: RFR: 8310906: Fix -Wconversion warnings in runtime,
 oops and some code header files.
In-Reply-To: <moXhLb2jOytefh6AdiUqTmvzvZBJrFV3RoJNZ7tLjbM=.39b74dd0-5f33-4cda-929e-7ccb2aaebfc5@github.com>
References: <moXhLb2jOytefh6AdiUqTmvzvZBJrFV3RoJNZ7tLjbM=.39b74dd0-5f33-4cda-929e-7ccb2aaebfc5@github.com>
Message-ID: <cvFU5-bB1oaJNU9duuKQLIaY-ZUhqrzUkpLoD_8PtEw=.a397423c-68f4-46e3-9781-e55468f06029@github.com>

On Mon, 26 Jun 2023 17:47:25 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> More casts for size of address differences in same code space, checked_casts<> and type changes to fix -Wconversion warnings.  See CR for details.
> Tested with tier1-4.

Changes requested by fparain (Reviewer).

src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 220:

> 218:     // If caller is interpreted it already made room for the callee arguments
> 219:     int overlap = caller.is_interpreted_frame() ? ContinuationHelper::InterpretedFrame::stack_argsize(hf) : 0;
> 220:     const int fsize = checked_cast<int>(ContinuationHelper::InterpretedFrame::frame_bottom(hf) - hf.unextended_sp() - overlap);

This line computes the size of the unextended frame minus the overlap that exists if the callee is using arguments in the caller?s frame. So this value is lower or equal to the frame? size which is encoded with an int. I don't think a checked_cast is required here. This applies to the x86 version too.

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

PR Review: https://git.openjdk.org/jdk/pull/14659#pullrequestreview-1499357905
PR Review Comment: https://git.openjdk.org/jdk/pull/14659#discussion_r1242721648

From aturbanov at openjdk.org  Mon Jun 26 21:00:02 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 26 Jun 2023 21:00:02 GMT
Subject: RFR: JDK-8310066: Improve test coverage for JVMTI GetThreadState
 on carrier and mounted vthread
In-Reply-To: <_8UnxXrT842BKmJ98GlmJyL21yzM0dhGOkeeK0Mnf2g=.c90b2826-922c-4838-b816-8bf3b5933d87@github.com>
References: <_8UnxXrT842BKmJ98GlmJyL21yzM0dhGOkeeK0Mnf2g=.c90b2826-922c-4838-b816-8bf3b5933d87@github.com>
Message-ID: <z2rrNBxFLFqhYKY_UMYK-qfucI6w9hkgnZLz80Naujg=.cec0551d-3d7f-4a78-bba1-5a61d3665900@github.com>

On Fri, 23 Jun 2023 01:57:56 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> This is follow-up JDK-8307153/JDK-8309612 (JVMTI GetThreadState on carrier should return STATE_WAITING)
> New test tests GetThreadState for different thread states.
> The test detected a bug in the implementation, new issue is created: JDK-8310584
> Corresponding testcases are commented now in the test, fix for JDK-8310584 will uncomment them

test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadStateMountedTest/GetThreadStateMountedTest.java line 85:

> 83:             }
> 84:         });
> 85:         synchronized(syncObj) {

Suggestion:

        synchronized (syncObj) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14622#discussion_r1242759252

From coleenp at openjdk.org  Mon Jun 26 21:31:04 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 26 Jun 2023 21:31:04 GMT
Subject: RFR: 8310906: Fix -Wconversion warnings in runtime,
 oops and some code header files.
In-Reply-To: <cvFU5-bB1oaJNU9duuKQLIaY-ZUhqrzUkpLoD_8PtEw=.a397423c-68f4-46e3-9781-e55468f06029@github.com>
References: <moXhLb2jOytefh6AdiUqTmvzvZBJrFV3RoJNZ7tLjbM=.39b74dd0-5f33-4cda-929e-7ccb2aaebfc5@github.com>
 <cvFU5-bB1oaJNU9duuKQLIaY-ZUhqrzUkpLoD_8PtEw=.a397423c-68f4-46e3-9781-e55468f06029@github.com>
Message-ID: <40BXpVD_kzHANHbpnaUqqDnHPb_OwvJgDby8AArm33k=.b073b265-f5ff-4327-b228-b5a2f69e1ca0@github.com>

On Mon, 26 Jun 2023 20:19:47 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> More casts for size of address differences in same code space, checked_casts<> and type changes to fix -Wconversion warnings.  See CR for details.
>> Tested with tier1-4.
>
> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 220:
> 
>> 218:     // If caller is interpreted it already made room for the callee arguments
>> 219:     int overlap = caller.is_interpreted_frame() ? ContinuationHelper::InterpretedFrame::stack_argsize(hf) : 0;
>> 220:     const int fsize = checked_cast<int>(ContinuationHelper::InterpretedFrame::frame_bottom(hf) - hf.unextended_sp() - overlap);
> 
> This line computes the size of the unextended frame minus the overlap that exists if the callee is using arguments in the caller?s frame. So this value is lower or equal to the frame? size which is encoded with an int. I don't think a checked_cast is required here. This applies to the x86 version too.

I'll make this change in the new PR.  I'm going to redo the address calculations to call a function rather than the casts.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14659#discussion_r1242788203

From coleenp at openjdk.org  Mon Jun 26 21:35:11 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 26 Jun 2023 21:35:11 GMT
Subject: Withdrawn: 8310906: Fix -Wconversion warnings in runtime,
 oops and some code header files.
In-Reply-To: <moXhLb2jOytefh6AdiUqTmvzvZBJrFV3RoJNZ7tLjbM=.39b74dd0-5f33-4cda-929e-7ccb2aaebfc5@github.com>
References: <moXhLb2jOytefh6AdiUqTmvzvZBJrFV3RoJNZ7tLjbM=.39b74dd0-5f33-4cda-929e-7ccb2aaebfc5@github.com>
Message-ID: <Ua0ypKT5VnPkCoeoTDkavwc2hOFG-mCfeeef3RB-vxQ=.15da19a4-783d-493c-9ace-85f3429b965b@github.com>

On Mon, 26 Jun 2023 17:47:25 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> More casts for size of address differences in same code space, checked_casts<> and type changes to fix -Wconversion warnings.  See CR for details.
> Tested with tier1-4.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/14659

From coleenp at openjdk.org  Mon Jun 26 21:35:11 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 26 Jun 2023 21:35:11 GMT
Subject: RFR: 8310906: Fix -Wconversion warnings in runtime,
 oops and some code header files.
In-Reply-To: <moXhLb2jOytefh6AdiUqTmvzvZBJrFV3RoJNZ7tLjbM=.39b74dd0-5f33-4cda-929e-7ccb2aaebfc5@github.com>
References: <moXhLb2jOytefh6AdiUqTmvzvZBJrFV3RoJNZ7tLjbM=.39b74dd0-5f33-4cda-929e-7ccb2aaebfc5@github.com>
Message-ID: <UzdxadWqP84Fj4ilYnmGGYnyUBjck9-Fgb7eg6A-pw4=.8184dd71-4467-4a0d-84ad-8790b1da6ddc@github.com>

On Mon, 26 Jun 2023 17:47:25 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> More casts for size of address differences in same code space, checked_casts<> and type changes to fix -Wconversion warnings.  See CR for details.
> Tested with tier1-4.

After some offline conversation with Ioi, we thought of a better way to express these pointer subtractions returning int, so I'm going to close this PR and open a new one with at least these changed with that new function.


// delta usually called with pointers or intptr_t that returns an int
// used for code buffer and other nearby address calculations.
// This allows the left side to be less than the right side.
template <typename T>
inline int delta_as_int(const volatile T left, const volatile T right) {
  return checked_cast<int>(left - right);
}

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

PR Comment: https://git.openjdk.org/jdk/pull/14659#issuecomment-1608292000

From dholmes at openjdk.org  Mon Jun 26 21:44:02 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 26 Jun 2023 21:44:02 GMT
Subject: RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit [v3]
In-Reply-To: <40ibXO2G3peem2lojRZ085yBDzKq3Dlha-RjJTkn9r8=.3be3d6d7-9e8a-4f3c-bcce-d03d63e3dc2b@github.com>
References: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
 <iWmku3kYvyGToSo-1zcSwnlquou7WJmhW8esd3sWMNs=.7dae028e-bdcd-4648-95d0-a317fe120fc3@github.com>
 <JAdzgg08g0qgkxQ8mIAsScvqmlzvFk09nB5qYgWYJKo=.2ae11d6e-f997-4dbc-9302-7bd5728db458@github.com>
 <8INVPbgTqA0Enqhog345Mxy44ZY6FCEkD_1NBotu9Mw=.59e217be-f65d-467a-8fed-f95288e1a162@github.com>
 <40ibXO2G3peem2lojRZ085yBDzKq3Dlha-RjJTkn9r8=.3be3d6d7-9e8a-4f3c-bcce-d03d63e3dc2b@github.com>
Message-ID: <JXt8ucZKu4k36uD1ViaZxvFpbzQg2VArTb-20xGJZqM=.fbef29a7-c220-4de0-b6a4-8d3ae7afde21@github.com>

On Mon, 26 Jun 2023 13:06:46 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> That's fine - if VMSupport fails class initialization, then no "rich" decoding can occur (by definition) and so throwing the clinit error is the best we can do.

Then why did you not simply handle the exception from the loading of VMSupport the same way?

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

PR Comment: https://git.openjdk.org/jdk/pull/14641#issuecomment-1608306762

From dnsimon at openjdk.org  Mon Jun 26 21:50:05 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 26 Jun 2023 21:50:05 GMT
Subject: RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit [v3]
In-Reply-To: <JXt8ucZKu4k36uD1ViaZxvFpbzQg2VArTb-20xGJZqM=.fbef29a7-c220-4de0-b6a4-8d3ae7afde21@github.com>
References: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
 <iWmku3kYvyGToSo-1zcSwnlquou7WJmhW8esd3sWMNs=.7dae028e-bdcd-4648-95d0-a317fe120fc3@github.com>
 <JAdzgg08g0qgkxQ8mIAsScvqmlzvFk09nB5qYgWYJKo=.2ae11d6e-f997-4dbc-9302-7bd5728db458@github.com>
 <8INVPbgTqA0Enqhog345Mxy44ZY6FCEkD_1NBotu9Mw=.59e217be-f65d-467a-8fed-f95288e1a162@github.com>
 <40ibXO2G3peem2lojRZ085yBDzKq3Dlha-RjJTkn9r8=.3be3d6d7-9e8a-4f3c-bcce-d03d63e3dc2b@github.com>
 <JXt8ucZKu4k36uD1ViaZxvFpbzQg2VArTb-20xGJZqM=.fbef29a7-c220-4de0-b6a4-8d3ae7afde21@github.com>
Message-ID: <Izz5oEDTU35jbtwcu09v7cRUKm4jZ43NLg1MEkZCm1Y=.9c982256-3ffa-4a69-93d7-88f1d5cf783b@github.com>

On Mon, 26 Jun 2023 21:41:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Then why did you not simply handle the exception from the loading of VMSupport the same way?

The only actual case seen of the original way failing is due to OOME in GC stress tests. If loading of VMSupport is done during VM startup, then no stress test code can cause an OOME while loading VMSupport. I doubt `VMSupport.<clinit>` would ever fail in practice.

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

PR Comment: https://git.openjdk.org/jdk/pull/14641#issuecomment-1608330027

From dholmes at openjdk.org  Mon Jun 26 21:59:02 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 26 Jun 2023 21:59:02 GMT
Subject: RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit [v3]
In-Reply-To: <Izz5oEDTU35jbtwcu09v7cRUKm4jZ43NLg1MEkZCm1Y=.9c982256-3ffa-4a69-93d7-88f1d5cf783b@github.com>
References: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
 <iWmku3kYvyGToSo-1zcSwnlquou7WJmhW8esd3sWMNs=.7dae028e-bdcd-4648-95d0-a317fe120fc3@github.com>
 <JAdzgg08g0qgkxQ8mIAsScvqmlzvFk09nB5qYgWYJKo=.2ae11d6e-f997-4dbc-9302-7bd5728db458@github.com>
 <8INVPbgTqA0Enqhog345Mxy44ZY6FCEkD_1NBotu9Mw=.59e217be-f65d-467a-8fed-f95288e1a162@github.com>
 <40ibXO2G3peem2lojRZ085yBDzKq3Dlha-RjJTkn9r8=.3be3d6d7-9e8a-4f3c-bcce-d03d63e3dc2b@github.com>
 <JXt8ucZKu4k36uD1ViaZxvFpbzQg2VArTb-20xGJZqM=.fbef29a7-c220-4de0-b6a4-8d3ae7afde21@github.com>
 <Izz5oEDTU35jbtwcu09v7cRUKm4jZ43NLg1MEkZCm1Y=.9c982256-3ffa-4a69-93d7-88f1d5cf783b@github.com>
Message-ID: <LEz4ibQJ0ko39cYn0n7n4O-fiL1p4ulzt-m_VE1yOsc=.50b7c9b7-f1bb-4097-acf4-a6e6c620d4f3@github.com>

On Mon, 26 Jun 2023 21:47:08 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>  I doubt VMSupport.<clinit> would ever fail in practice.

I would think it is likely to fail with OOME under the same GC stress test conditions.

But if this is just a stress test issue then bailing out when the loading fails would be far simpler than pre-loading the class. You've added to the VM startup cost just to avoid a stress test failure.

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

PR Comment: https://git.openjdk.org/jdk/pull/14641#issuecomment-1608371203

From dnsimon at openjdk.org  Mon Jun 26 22:13:22 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 26 Jun 2023 22:13:22 GMT
Subject: RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit [v3]
In-Reply-To: <LEz4ibQJ0ko39cYn0n7n4O-fiL1p4ulzt-m_VE1yOsc=.50b7c9b7-f1bb-4097-acf4-a6e6c620d4f3@github.com>
References: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
 <iWmku3kYvyGToSo-1zcSwnlquou7WJmhW8esd3sWMNs=.7dae028e-bdcd-4648-95d0-a317fe120fc3@github.com>
 <JAdzgg08g0qgkxQ8mIAsScvqmlzvFk09nB5qYgWYJKo=.2ae11d6e-f997-4dbc-9302-7bd5728db458@github.com>
 <8INVPbgTqA0Enqhog345Mxy44ZY6FCEkD_1NBotu9Mw=.59e217be-f65d-467a-8fed-f95288e1a162@github.com>
 <40ibXO2G3peem2lojRZ085yBDzKq3Dlha-RjJTkn9r8=.3be3d6d7-9e8a-4f3c-bcce-d03d63e3dc2b@github.com>
 <JXt8ucZKu4k36uD1ViaZxvFpbzQg2VArTb-20xGJZqM=.fbef29a7-c220-4de0-b6a4-8d3ae7afde21@github.com>
 <Izz5oEDTU35jbtwcu09v7cRUKm4jZ43NLg1MEkZCm1Y=.9c982256-3ffa-4a69-93d7-88f1d5cf783b@github.com>
 <LEz4ibQJ0ko39cYn0n7n4O-fiL1p4ulzt-m_VE1yOsc=.50b7c9b7-f1bb-4097-acf4-a6e6c620d4f3@github.com>
Message-ID: <yCmxHyd854I6E_I9VFSSlgwUKkUU7-1QKD6_ZWcSEwY=.7b3d34e3-31ca-40bf-b85d-5c3b5498ac5f@github.com>

On Mon, 26 Jun 2023 21:56:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I would think it is likely to fail with OOME under the same GC stress test conditions.
> 
> But if this is just a stress test issue then bailing out when the loading fails would be far simpler than pre-loading the class. You've added to the VM startup cost just to avoid a stress test failure.

Any app running near the GC limit can cause this and we've seen this with libgraal in practice. When the VM is near the GC limit, any compilation can cause an OOME and then when that OOME wants to be translated back to libgraal, it can be the first time VMSupport is used.
The time for loading `VMSupport` eagerly is in the noise.
For example, `-verbose:class` shows that about 30 classes (including `VMSupport`) are loaded in 1ms:

[0.011s][info][class,load] java.lang.reflect.Executable source: shared objects file
[0.012s][info][class,load] java.lang.reflect.Method source: shared objects file
[0.012s][info][class,load] java.lang.reflect.Constructor source: shared objects file
[0.012s][info][class,load] jdk.internal.vm.ContinuationScope source: shared objects file
[0.012s][info][class,load] jdk.internal.vm.Continuation source: shared objects file
[0.012s][info][class,load] jdk.internal.vm.StackChunk source: shared objects file
[0.012s][info][class,load] jdk.internal.vm.VMSupport source: shared objects file
[0.012s][info][class,load] jdk.internal.reflect.MagicAccessorImpl source: shared objects file
[0.012s][info][class,load] jdk.internal.reflect.MethodAccessor source: shared objects file
[0.012s][info][class,load] jdk.internal.reflect.MethodAccessorImpl source: shared objects file
[0.012s][info][class,load] jdk.internal.reflect.DelegatingClassLoader source: shared objects file
[0.012s][info][class,load] jdk.internal.reflect.ConstantPool source: shared objects file
[0.012s][info][class,load] java.lang.annotation.Annotation source: shared objects file
[0.012s][info][class,load] jdk.internal.reflect.CallerSensitive source: shared objects file
[0.012s][info][class,load] jdk.internal.reflect.ConstructorAccessor source: shared objects file
[0.012s][info][class,load] jdk.internal.reflect.ConstructorAccessorImpl source: shared objects file
[0.012s][info][class,load] jdk.internal.reflect.DirectConstructorHandleAccessor$NativeAccessor source: shared objects file
[0.012s][info][class,load] jdk.internal.reflect.SerializationConstructorAccessorImpl source: shared objects file
[0.012s][info][class,load] java.lang.invoke.MethodHandle source: shared objects file
[0.012s][info][class,load] java.lang.invoke.DirectMethodHandle source: shared objects file
[0.012s][info][class,load] java.lang.invoke.VarHandle source: shared objects file
[0.012s][info][class,load] java.lang.invoke.MemberName source: shared objects file
[0.012s][info][class,load] java.lang.invoke.ResolvedMethodName source: shared objects file
[0.012s][info][class,load] java.lang.invoke.MethodHandleNatives source: shared objects file
[0.012s][info][class,load] java.lang.invoke.LambdaForm source: shared objects file
[0.012s][info][class,load] java.lang.invoke.TypeDescriptor$OfMethod source: shared objects file
[0.012s][info][class,load] java.lang.invoke.MethodType source: shared objects file
[0.012s][info][class,load] java.lang.BootstrapMethodError source: shared objects file
[0.012s][info][class,load] java.lang.invoke.CallSite source: shared objects file
[0.012s][info][class,load] jdk.internal.foreign.abi.NativeEntryPoint source: shared objects file
[0.012s][info][class,load] jdk.internal.foreign.abi.ABIDescriptor source: shared objects file
[0.012s][info][class,load] jdk.internal.foreign.abi.VMStorage source: shared objects file
[0.013s][info][class,load] jdk.internal.foreign.abi.UpcallLinker$CallRegs source: shared objects file

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

PR Comment: https://git.openjdk.org/jdk/pull/14641#issuecomment-1608388679

From dholmes at openjdk.org  Mon Jun 26 23:24:03 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 26 Jun 2023 23:24:03 GMT
Subject: RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit [v3]
In-Reply-To: <bY4wAhAD6sOLr0zuHQJ6tMkD6shiL4RwnL7kIxk91YI=.03848181-fa09-4988-bd9d-7d0dc4e85d49@github.com>
References: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
 <bY4wAhAD6sOLr0zuHQJ6tMkD6shiL4RwnL7kIxk91YI=.03848181-fa09-4988-bd9d-7d0dc4e85d49@github.com>
Message-ID: <JZPglxrLE6CnoqAucxL3iyphTkKVMKbREJUbCah-bkk=.c0415229-d95f-4e7b-9d59-e9fe1b70fd2d@github.com>

On Mon, 26 Jun 2023 13:17:25 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> The VMSupport class is required for translating an exception between the HotSpot and libgraal heaps.
>> Loading it lazily can result in a loading exception, obscuring the exception being translated.
>> To avoid this, VMSupport is loaded eagerly along with the other vmClasses.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   each exception translation failure should trigger a JVMCI event

It may be in the noise but noise adds up over time.

It just seems to me that the simplest fix here would have been to convert

Klass* vmSupport = SystemDictionary::resolve_or_fail(vmSymbols::jdk_internal_vm_VMSupport(), true, THREAD);
guarantee(!HAS_PENDING_EXCEPTION, "");

to

Klass* vmSupport = SystemDictionary::resolve_or_fail(vmSymbols::jdk_internal_vm_VMSupport(), true, CHECK);

and just return on exception. A very isolated change with zero impact on anything else.

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

PR Comment: https://git.openjdk.org/jdk/pull/14641#issuecomment-1608455121

From cjplummer at openjdk.org  Tue Jun 27 04:27:04 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 27 Jun 2023 04:27:04 GMT
Subject: RFR: 8309979: BootstrapMethods attribute is missing in class files
 recreated by SA [v3]
In-Reply-To: <AP8yKMhhMNIqR5yvcLylrZcoiMh7riMYbxK4jpAwpCs=.79aa5a8f-670b-43d2-815c-245fe8d47868@github.com>
References: <nSooA6CtKm8LsaxzYdqJ6mtVV0os-kT5F2xNvYI4lJo=.c27bd28e-88d3-4bcb-ac3d-9036140eeff0@github.com>
 <AP8yKMhhMNIqR5yvcLylrZcoiMh7riMYbxK4jpAwpCs=.79aa5a8f-670b-43d2-815c-245fe8d47868@github.com>
Message-ID: <hhknxf54Ql2Fq-e09IgGqVRZr1DFgGQzyWQjuIsLydo=.000d9195-00e2-4edd-bc33-1c6b81997c19@github.com>

On Thu, 22 Jun 2023 15:37:11 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> Please review this PR that extends SA to write BootstrapMethods attribute when dumping the class files.
>> 
>> Tested it by dumping the class file for java/lang/String and comparing the BootstrapMethods attribute shown by javap for the original and the dumped class.
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment about the layout of operands array in constant pool
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14495#pullrequestreview-1499916073

From coleenp at openjdk.org  Tue Jun 27 12:49:28 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 27 Jun 2023 12:49:28 GMT
Subject: RFR: 8310906: Fix -Wconversion warnings in runtime,
 oops and some code header files.
Message-ID: <hvRAKRMNH1sBjeP5Ikhc5zt-4uyasNOEQ9Z0AeQbyAA=.64bdd842-d4b6-420d-a4e2-409567eb66b1@github.com>

This is another version of PR https://github.com/openjdk/jdk/pull/14659 but I've added a pointer delta function in globalDefinitions.hpp to use for these pointer diff calculations that return int everywhere.  If the name is agreeable, I'll fix the other cases of this like this.  It's better than raw casts.
Tested with tier1-4.

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

Commit messages:
 - 8310906: Fix -Wconversion warnings in runtime, oops and some code header files.

Changes: https://git.openjdk.org/jdk/pull/14675/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14675&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310906
  Stats: 59 lines in 31 files changed: 8 ins; 0 del; 51 mod
  Patch: https://git.openjdk.org/jdk/pull/14675.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14675/head:pull/14675

PR: https://git.openjdk.org/jdk/pull/14675

From duke at openjdk.org  Tue Jun 27 13:17:07 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Tue, 27 Jun 2023 13:17:07 GMT
Subject: RFR: 8309979: BootstrapMethods attribute is missing in class files
 recreated by SA [v2]
In-Reply-To: <qu7fBUROq67BjS_SohvC0J-ivzwRpZXH168nsve-66Y=.6bcc526f-b04c-44d8-859c-d516a43067bc@github.com>
References: <nSooA6CtKm8LsaxzYdqJ6mtVV0os-kT5F2xNvYI4lJo=.c27bd28e-88d3-4bcb-ac3d-9036140eeff0@github.com>
 <i3PjGx_wbQ63SlwcWL5eBr28sDUb1_dPQ8Q0P3Qgzds=.5f11a8e5-714c-45c0-87e6-e612bb50b28b@github.com>
 <BcYUruTksAAC-JjG4G97NDGp-757WOzZgZjfjJjg2LA=.9e7ef15b-b1cf-430f-85cb-c9ca06576b96@github.com>
 <qu7fBUROq67BjS_SohvC0J-ivzwRpZXH168nsve-66Y=.6bcc526f-b04c-44d8-859c-d516a43067bc@github.com>
Message-ID: <Aom8rx_nyW-XomCAr2UNNarJDctVzwwLFgQ570fEvpQ=.d7e500d7-a7f3-4a48-8ea6-0887585668fe@github.com>

On Thu, 22 Jun 2023 16:10:13 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

> I am thinking of a comprehensive test that creates a classfile with specific attribute, load it in the VM, dump that class file using SA, then disassemble the generated class file to check for the presence of the attribute. We would also need some mechanism to ensure all attributes and cp tags supported by the VM level being tested are covered. Does that sound feasible?

I am working on a test case that uses `buildreplayjars` command to dump the boot and app classfiles and reuse them to run the same application again. I think that would provide good coverage for classfile dumping functionality as well and would remove the requirement to check every other attribute in the dumped classfile. 
But the new test currently fails because we are not dumping many of the attributes in the classfile. So far I have added support for Annotations, NestMembers and NestHost. Once I have the test working I will open the PR to add it.

As for this PR, we can either wait for the new test and other changes to be ready, or integrate it based on the manual testing. I don't mind either approach.

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

PR Comment: https://git.openjdk.org/jdk/pull/14495#issuecomment-1609484548

From stefank at openjdk.org  Tue Jun 27 13:31:11 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 27 Jun 2023 13:31:11 GMT
Subject: RFR: 8310906: Fix -Wconversion warnings in runtime,
 oops and some code header files.
In-Reply-To: <hvRAKRMNH1sBjeP5Ikhc5zt-4uyasNOEQ9Z0AeQbyAA=.64bdd842-d4b6-420d-a4e2-409567eb66b1@github.com>
References: <hvRAKRMNH1sBjeP5Ikhc5zt-4uyasNOEQ9Z0AeQbyAA=.64bdd842-d4b6-420d-a4e2-409567eb66b1@github.com>
Message-ID: <L3kD9sU0DxRbVwVhIMQMo3GXFnAx-N7hiOs94cxufQM=.c8b482e4-a1a1-4148-87c4-ab8a4cc7424b@github.com>

On Tue, 27 Jun 2023 12:41:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is another version of PR https://github.com/openjdk/jdk/pull/14659 but I've added a pointer delta function in globalDefinitions.hpp to use for these pointer diff calculations that return int everywhere.  If the name is agreeable, I'll fix the other cases of this like this.  It's better than raw casts.
> Tested with tier1-4.

src/hotspot/share/code/codeBlob.inline.hpp line 36:

> 34: inline const ImmutableOopMap* CodeBlob::oop_map_for_slot(int slot, address return_address) const {
> 35:   assert(_oop_maps != nullptr, "nope");
> 36:   return _oop_maps->find_map_at_slot(slot, delta_as_int((intptr_t) return_address, (intptr_t) code_begin()));

Is this the only usage of `delta_as_int` that operates on `intptr_t`? If we remove the casts then all usages would operate on pointers. Maybe this is an indication that we only need a `pointer_delta_as_int` function, to go hand in hand with the other `pointer_delta` functions?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14675#discussion_r1243696287

From kevinw at openjdk.org  Tue Jun 27 13:36:07 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 27 Jun 2023 13:36:07 GMT
Subject: RFR: 8309979: BootstrapMethods attribute is missing in class files
 recreated by SA [v3]
In-Reply-To: <AP8yKMhhMNIqR5yvcLylrZcoiMh7riMYbxK4jpAwpCs=.79aa5a8f-670b-43d2-815c-245fe8d47868@github.com>
References: <nSooA6CtKm8LsaxzYdqJ6mtVV0os-kT5F2xNvYI4lJo=.c27bd28e-88d3-4bcb-ac3d-9036140eeff0@github.com>
 <AP8yKMhhMNIqR5yvcLylrZcoiMh7riMYbxK4jpAwpCs=.79aa5a8f-670b-43d2-815c-245fe8d47868@github.com>
Message-ID: <Po3Q3J2d8-l9h52IQJ9RrfOunLeZ2Ey_4_AB4uPzc2I=.511f55cf-bb8b-4be4-8251-89db124f97f4@github.com>

On Thu, 22 Jun 2023 15:37:11 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> Please review this PR that extends SA to write BootstrapMethods attribute when dumping the class files.
>> 
>> Tested it by dumping the class file for java/lang/String and comparing the BootstrapMethods attribute shown by javap for the original and the dumped class.
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment about the layout of operands array in constant pool
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

(I intended to click 'approve' earlier!)

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

Marked as reviewed by kevinw (Committer).

PR Review: https://git.openjdk.org/jdk/pull/14495#pullrequestreview-1500887539

From mbaesken at openjdk.org  Tue Jun 27 13:45:27 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 27 Jun 2023 13:45:27 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work [v4]
In-Reply-To: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
Message-ID: <tdhFvurYKJgIVFAThJ7bZzFgVGR2VWsUnmye2-ZZT8Q=.b56d19ad-1efd-4896-b576-44c315465578@github.com>

> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
> But without the entitlement, a core is not generated.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  small adjustments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14562/files
  - new: https://git.openjdk.org/jdk/pull/14562/files/619b3578..09eb93c6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14562&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14562&range=02-03

  Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14562.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14562/head:pull/14562

PR: https://git.openjdk.org/jdk/pull/14562

From mbaesken at openjdk.org  Tue Jun 27 13:45:29 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 27 Jun 2023 13:45:29 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work [v3]
In-Reply-To: <LdyQw-4zZwjHIW1MC9q43Nekj30shwvyJBaNbPsLg54=.bb966145-68be-4e46-89a5-12c1f0b9048e@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
 <LdyQw-4zZwjHIW1MC9q43Nekj30shwvyJBaNbPsLg54=.bb966145-68be-4e46-89a5-12c1f0b9048e@github.com>
Message-ID: <30dMjVyi4aRjn9GA1WW4kRM9-fvnBKykEuEHk58ZosI=.70b4a1f4-f7b5-45ea-afd1-3bdbd2f0fe9a@github.com>

On Thu, 22 Jun 2023 11:51:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
>> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
>> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
>> But without the entitlement, a core is not generated.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move javaPath into caller

Hi Chris,  I renamed the method and adjusted the comment.

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

PR Comment: https://git.openjdk.org/jdk/pull/14562#issuecomment-1609529567

From duke at openjdk.org  Tue Jun 27 13:46:13 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Tue, 27 Jun 2023 13:46:13 GMT
Subject: RFR: 8309979: BootstrapMethods attribute is missing in class files
 recreated by SA [v2]
In-Reply-To: <XMnH_cFQgCnx13I_1SqV-Br6T1QDwlbz9FzQZ-HlEaE=.f93bc591-726f-45fe-95ac-d1d6cfe79d06@github.com>
References: <nSooA6CtKm8LsaxzYdqJ6mtVV0os-kT5F2xNvYI4lJo=.c27bd28e-88d3-4bcb-ac3d-9036140eeff0@github.com>
 <i3PjGx_wbQ63SlwcWL5eBr28sDUb1_dPQ8Q0P3Qgzds=.5f11a8e5-714c-45c0-87e6-e612bb50b28b@github.com>
 <XMnH_cFQgCnx13I_1SqV-Br6T1QDwlbz9FzQZ-HlEaE=.f93bc591-726f-45fe-95ac-d1d6cfe79d06@github.com>
Message-ID: <caUQ5UnNCwqKelNQetmRxPar0qErChaf7OX8KtuO7gk=.9b1b3eac-11a5-4711-a861-fd0a7476cd58@github.com>

On Fri, 16 Jun 2023 18:10:58 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments by plummercj
>>   
>>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> Yes, it is already problem listed. How did you run the tests? If you use "make test" it should be including the problem list automatically.

Thanks @plummercj @kevinjwalls @sspitsyn for reviewing the PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/14495#issuecomment-1609535045

From djelinski at openjdk.org  Tue Jun 27 14:56:26 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 27 Jun 2023 14:56:26 GMT
Subject: RFR: 8310948: Fix ignored-qualifiers warning in Hotspot
Message-ID: <hNI7tUjnrrsVnOlgJUzzLywNXljokcIjUBuH3DgtHdE=.f26e72bb-591f-48f1-8dfe-f4c85254b72f@github.com>

Please review this attempt to fix ignored-qualifiers warning.

Example warnings:

src/hotspot/share/oops/method.hpp:413:19: warning: 'volatile' type qualifier on return type has no effect [-Wignored-qualifiers]
   CompiledMethod* volatile code() const;
                   ^~~~~~~~~


src/hotspot/share/jfr/periodic/jfrModuleEvent.cpp:65:20: warning: type qualifiers ignored on cast result type [-Wignored-qualifiers]
    65 |   event.set_source((const ModuleEntry* const)from_module);
       |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


The proposed fix removes the ignored qualifiers.
In a few AD files I replaced `const` with `constexpr` where I noticed that the method is returning a compile-time constant, and other platforms use `constexpr` on the same method.

Release, debug and slowdebug builds on Aarch64 / x64 and Mac / Linux complete without errors. Cross-compile GHA builds also pass.

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

Commit messages:
 - Fix other platforms
 - Fix shenandoah
 - Fix ignored-qualifiers warning

Changes: https://git.openjdk.org/jdk/pull/14674/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14674&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310948
  Stats: 223 lines in 74 files changed: 0 ins; 0 del; 223 mod
  Patch: https://git.openjdk.org/jdk/pull/14674.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14674/head:pull/14674

PR: https://git.openjdk.org/jdk/pull/14674

From coleenp at openjdk.org  Tue Jun 27 14:57:06 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 27 Jun 2023 14:57:06 GMT
Subject: RFR: 8310906: Fix -Wconversion warnings in runtime,
 oops and some code header files.
In-Reply-To: <L3kD9sU0DxRbVwVhIMQMo3GXFnAx-N7hiOs94cxufQM=.c8b482e4-a1a1-4148-87c4-ab8a4cc7424b@github.com>
References: <hvRAKRMNH1sBjeP5Ikhc5zt-4uyasNOEQ9Z0AeQbyAA=.64bdd842-d4b6-420d-a4e2-409567eb66b1@github.com>
 <L3kD9sU0DxRbVwVhIMQMo3GXFnAx-N7hiOs94cxufQM=.c8b482e4-a1a1-4148-87c4-ab8a4cc7424b@github.com>
Message-ID: <7jCGpmw9yQYwUzVAR8Ytaj3TiUWSFOscyMlkkg4Abvs=.f6f65abf-b3f3-4718-87b6-d0c78d82038d@github.com>

On Tue, 27 Jun 2023 12:59:59 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> This is another version of PR https://github.com/openjdk/jdk/pull/14659 but I've added a pointer delta function in globalDefinitions.hpp to use for these pointer diff calculations that return int everywhere.  If the name is agreeable, I'll fix the other cases of this like this.  It's better than raw casts.
>> Tested with tier1-4.
>
> src/hotspot/share/code/codeBlob.inline.hpp line 36:
> 
>> 34: inline const ImmutableOopMap* CodeBlob::oop_map_for_slot(int slot, address return_address) const {
>> 35:   assert(_oop_maps != nullptr, "nope");
>> 36:   return _oop_maps->find_map_at_slot(slot, delta_as_int((intptr_t) return_address, (intptr_t) code_begin()));
> 
> Is this the only usage of `delta_as_int` that operates on `intptr_t`? If we remove the casts then all usages would operate on pointers. Maybe this is an indication that we only need a `pointer_delta_as_int` function, to go hand in hand with the other `pointer_delta` functions?

Hm.  Maybe this would be ok. Our original idea was to make it T* not T until this cast.  I don't know how many other cases there are that I haven't gotten to yet.  But it would eliminate a cast, so that's good (unless these aren't the same).  Some instances have ptr - constant that gets promoted I think.
The reason we didn't pick pointer_delta_as_int because pointer_delta has different semantics.  pointer_delta insists on positive results.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14675#discussion_r1243892244

From coleenp at openjdk.org  Tue Jun 27 15:16:27 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 27 Jun 2023 15:16:27 GMT
Subject: RFR: 8310906: Fix -Wconversion warnings in runtime,
 oops and some code header files. [v2]
In-Reply-To: <hvRAKRMNH1sBjeP5Ikhc5zt-4uyasNOEQ9Z0AeQbyAA=.64bdd842-d4b6-420d-a4e2-409567eb66b1@github.com>
References: <hvRAKRMNH1sBjeP5Ikhc5zt-4uyasNOEQ9Z0AeQbyAA=.64bdd842-d4b6-420d-a4e2-409567eb66b1@github.com>
Message-ID: <oyRaDnv1ETd8wH9NO6MABLh6oLmj00wmgZRtu7BL2sQ=.e914f0bd-b88b-4c2c-b859-42bb03dc21e2@github.com>

> This is another version of PR https://github.com/openjdk/jdk/pull/14659 but I've added a pointer delta function in globalDefinitions.hpp to use for these pointer diff calculations that return int everywhere.  If the name is agreeable, I'll fix the other cases of this like this.  It's better than raw casts.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Make delta_as_int take pointers and fix cast.  Missed one in stubCodeGenerator.hpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14675/files
  - new: https://git.openjdk.org/jdk/pull/14675/files/9b7fdef2..99a15d6e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14675&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14675&range=00-01

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14675.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14675/head:pull/14675

PR: https://git.openjdk.org/jdk/pull/14675

From coleenp at openjdk.org  Tue Jun 27 15:16:28 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 27 Jun 2023 15:16:28 GMT
Subject: RFR: 8310906: Fix -Wconversion warnings in runtime,
 oops and some code header files. [v2]
In-Reply-To: <7jCGpmw9yQYwUzVAR8Ytaj3TiUWSFOscyMlkkg4Abvs=.f6f65abf-b3f3-4718-87b6-d0c78d82038d@github.com>
References: <hvRAKRMNH1sBjeP5Ikhc5zt-4uyasNOEQ9Z0AeQbyAA=.64bdd842-d4b6-420d-a4e2-409567eb66b1@github.com>
 <L3kD9sU0DxRbVwVhIMQMo3GXFnAx-N7hiOs94cxufQM=.c8b482e4-a1a1-4148-87c4-ab8a4cc7424b@github.com>
 <7jCGpmw9yQYwUzVAR8Ytaj3TiUWSFOscyMlkkg4Abvs=.f6f65abf-b3f3-4718-87b6-d0c78d82038d@github.com>
Message-ID: <c2RZS7gtSPZJzchcDSd5IOAkTMRag-F3JHOTpLOIBzc=.09b3bbad-2587-45cc-8d7b-a6b540994549@github.com>

On Tue, 27 Jun 2023 14:54:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/code/codeBlob.inline.hpp line 36:
>> 
>>> 34: inline const ImmutableOopMap* CodeBlob::oop_map_for_slot(int slot, address return_address) const {
>>> 35:   assert(_oop_maps != nullptr, "nope");
>>> 36:   return _oop_maps->find_map_at_slot(slot, delta_as_int((intptr_t) return_address, (intptr_t) code_begin()));
>> 
>> Is this the only usage of `delta_as_int` that operates on `intptr_t`? If we remove the casts then all usages would operate on pointers. Maybe this is an indication that we only need a `pointer_delta_as_int` function, to go hand in hand with the other `pointer_delta` functions?
>
> Hm.  Maybe this would be ok. Our original idea was to make it T* not T until this cast.  I don't know how many other cases there are that I haven't gotten to yet.  But it would eliminate a cast, so that's good (unless these aren't the same).  Some instances have ptr - constant that gets promoted I think.
> The reason we didn't pick pointer_delta_as_int because pointer_delta has different semantics.  pointer_delta insists on positive results.

Taking out that cast does work, so I've fixed that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14675#discussion_r1243922324

From egor.ushakov at jetbrains.com  Tue Jun 27 15:58:42 2023
From: egor.ushakov at jetbrains.com (Egor Ushakov)
Date: Tue, 27 Jun 2023 17:58:42 +0200
Subject: jdwp virtual threads dump?
Message-ID: <aec90007-67b1-9b3a-0a59-7e8721d76a25@jetbrains.com>

Hi all,

is there a way for a debugger to create a virtual threads dump via jdwp?

Thanks,
Egor

From Alan.Bateman at oracle.com  Tue Jun 27 16:24:13 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 27 Jun 2023 17:24:13 +0100
Subject: jdwp virtual threads dump?
In-Reply-To: <aec90007-67b1-9b3a-0a59-7e8721d76a25@jetbrains.com>
References: <aec90007-67b1-9b3a-0a59-7e8721d76a25@jetbrains.com>
Message-ID: <ae05aa95-cbf7-e2e0-a124-e44cc43a1b86@oracle.com>

On 27/06/2023 16:58, Egor Ushakov wrote:
> Hi all,
>
> is there a way for a debugger to create a virtual threads dump via jdwp?

Right now, the only way to do this via JDWP is use the 
ObjectReference/InvokeMethod command (or JDI invokeMethod at the API 
level) to invoke HotSpotDiagnosticMXBean dumpThreads to generate a 
thread dump to a file. So not terrible when the debugger and target VM 
are on the same system or at least have access to the same file system. 
In the future, JDWP + JDI will require updates to define new 
commands/methods to find threads, the VirtualMachine/AllThreads command 
is not the right solution for virtual threads.

BTW: What does IDEA "Get Thread Dump" (camera icon) use?

-Alan

From egor.ushakov at jetbrains.com  Tue Jun 27 16:52:59 2023
From: egor.ushakov at jetbrains.com (Egor Ushakov)
Date: Tue, 27 Jun 2023 18:52:59 +0200
Subject: jdwp virtual threads dump?
In-Reply-To: <ae05aa95-cbf7-e2e0-a124-e44cc43a1b86@oracle.com>
References: <aec90007-67b1-9b3a-0a59-7e8721d76a25@jetbrains.com>
 <ae05aa95-cbf7-e2e0-a124-e44cc43a1b86@oracle.com>
Message-ID: <28ec4a5f-6959-4692-0495-4136f9f7e7d9@jetbrains.com>

Thanks Alan!

for now there's no special support for virtual threads in IDEA, that's 
why I'm asking :)

"Get Thread Dump" action gathers the information from the threads list 
provided by com.sun.jdi.VirtualMachine#allThreads.

-Egor

On 27.06.2023 18:24, Alan Bateman wrote:
> On 27/06/2023 16:58, Egor Ushakov wrote:
>> Hi all,
>>
>> is there a way for a debugger to create a virtual threads dump via jdwp?
>
> Right now, the only way to do this via JDWP is use the 
> ObjectReference/InvokeMethod command (or JDI invokeMethod at the API 
> level) to invoke HotSpotDiagnosticMXBean dumpThreads to generate a 
> thread dump to a file. So not terrible when the debugger and target VM 
> are on the same system or at least have access to the same file 
> system. In the future, JDWP + JDI will require updates to define new 
> commands/methods to find threads, the VirtualMachine/AllThreads 
> command is not the right solution for virtual threads.
>
> BTW: What does IDEA "Get Thread Dump" (camera icon) use?
>
> -Alan


From cjplummer at openjdk.org  Tue Jun 27 19:19:05 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 27 Jun 2023 19:19:05 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work [v4]
In-Reply-To: <tdhFvurYKJgIVFAThJ7bZzFgVGR2VWsUnmye2-ZZT8Q=.b56d19ad-1efd-4896-b576-44c315465578@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
 <tdhFvurYKJgIVFAThJ7bZzFgVGR2VWsUnmye2-ZZT8Q=.b56d19ad-1efd-4896-b576-44c315465578@github.com>
Message-ID: <BMeqMTX0eNi2J8xMdXah2MAgL_IyWhggqueqb7DlZEU=.ee015530-c9ee-4d42-84c9-177ccba6ce82@github.com>

On Tue, 27 Jun 2023 13:45:27 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
>> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
>> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
>> But without the entitlement, a core is not generated.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   small adjustments

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14562#pullrequestreview-1501681509

From never at openjdk.org  Tue Jun 27 20:00:13 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Tue, 27 Jun 2023 20:00:13 GMT
Subject: RFR: 8294316: SA core file support is broken on macosx-x64
 starting with macOS 12.x [v4]
In-Reply-To: <2vbBaOc6yp_JozXoDxdwwOMK51xxmumzbK-84EEB4HY=.d53a282d-e680-4a76-a1a1-d92a397ae335@github.com>
References: <0wPtkRqjB3Nh6LiABARFcqq6UqcCsTNbF1ok1iG0Efw=.af55940f-5b2d-4cfb-b233-066a419bae48@github.com>
 <2vbBaOc6yp_JozXoDxdwwOMK51xxmumzbK-84EEB4HY=.d53a282d-e680-4a76-a1a1-d92a397ae335@github.com>
Message-ID: <l77kFdgKEiCA_Y94-pbrXvgBR_ZlXGbd1szZMTR5iYI=.ae9019dc-ee5d-43cf-9581-91d03e2c5d65@github.com>

On Mon, 26 Jun 2023 18:09:24 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> This is a minor fix to core file reading on macos x.  I can confirm that after this fix I can run the problem listed SA core file tests on Ventura.
>
> Tom Rodriguez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/14569#issuecomment-1610129056

From never at openjdk.org  Tue Jun 27 20:00:15 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Tue, 27 Jun 2023 20:00:15 GMT
Subject: Integrated: 8294316: SA core file support is broken on macosx-x64
 starting with macOS 12.x
In-Reply-To: <0wPtkRqjB3Nh6LiABARFcqq6UqcCsTNbF1ok1iG0Efw=.af55940f-5b2d-4cfb-b233-066a419bae48@github.com>
References: <0wPtkRqjB3Nh6LiABARFcqq6UqcCsTNbF1ok1iG0Efw=.af55940f-5b2d-4cfb-b233-066a419bae48@github.com>
Message-ID: <gMld_tkpW3DPb9YQnMKJi0Okd6QFqHa6PxReXZkVklk=.bc3fab2e-c7da-444e-9677-3f4f1d0c5c36@github.com>

On Tue, 20 Jun 2023 18:05:09 GMT, Tom Rodriguez <never at openjdk.org> wrote:

> This is a minor fix to core file reading on macos x.  I can confirm that after this fix I can run the problem listed SA core file tests on Ventura.

This pull request has now been integrated.

Changeset: 269852b9
Author:    Tom Rodriguez <never at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/269852b90634aa43d4d719c93563608e42792fc6
Stats:     17 lines in 2 files changed: 5 ins; 0 del; 12 mod

8294316: SA core file support is broken on macosx-x64 starting with macOS 12.x

Reviewed-by: cjplummer, sspitsyn

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

PR: https://git.openjdk.org/jdk/pull/14569

From amenkov at openjdk.org  Tue Jun 27 20:38:11 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 27 Jun 2023 20:38:11 GMT
Subject: Integrated: 8310585: GetThreadState spec mentions undefined
 JVMTI_THREAD_STATE_MONITOR_WAITING
In-Reply-To: <cS0KuoYy8kK2zVNJ733E-oXIAQyVqDuEgKm9RKKxipk=.5e2c01d5-97f8-4df3-a569-e7f5ea127df0@github.com>
References: <cS0KuoYy8kK2zVNJ733E-oXIAQyVqDuEgKm9RKKxipk=.5e2c01d5-97f8-4df3-a569-e7f5ea127df0@github.com>
Message-ID: <M8m-dSvexBop5k3zZV3oG_y5qn4510Kq4OaI9vEalSg=.4bb55bdb-cb81-41a2-a4f1-c541c496d278@github.com>

On Fri, 23 Jun 2023 22:59:54 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Trivial fix in JVMTI spec.
> As it's just a typo, CSR is not required

This pull request has now been integrated.

Changeset: a97f98fb
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a97f98fb8a933b43cd4485c3791ac8ca016bc49f
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8310585: GetThreadState spec mentions undefined JVMTI_THREAD_STATE_MONITOR_WAITING

Reviewed-by: sspitsyn, cjplummer

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

PR: https://git.openjdk.org/jdk/pull/14634

From coleenp at openjdk.org  Tue Jun 27 20:48:27 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 27 Jun 2023 20:48:27 GMT
Subject: RFR: 8310906: Fix -Wconversion warnings in runtime,
 oops and some code header files. [v3]
In-Reply-To: <hvRAKRMNH1sBjeP5Ikhc5zt-4uyasNOEQ9Z0AeQbyAA=.64bdd842-d4b6-420d-a4e2-409567eb66b1@github.com>
References: <hvRAKRMNH1sBjeP5Ikhc5zt-4uyasNOEQ9Z0AeQbyAA=.64bdd842-d4b6-420d-a4e2-409567eb66b1@github.com>
Message-ID: <nY6ZCwe0ts6wSaUCDJb0LFVsMXmMCpV_tE-XVZOibc0=.9d5802cb-edd3-4c36-93e5-4c19da5d2cc3@github.com>

> This is another version of PR https://github.com/openjdk/jdk/pull/14659 but I've added a pointer delta function in globalDefinitions.hpp to use for these pointer diff calculations that return int everywhere.  If the name is agreeable, I'll fix the other cases of this like this.  It's better than raw casts.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fixed the comment.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14675/files
  - new: https://git.openjdk.org/jdk/pull/14675/files/99a15d6e..858e9cfb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14675&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14675&range=01-02

  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14675.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14675/head:pull/14675

PR: https://git.openjdk.org/jdk/pull/14675

From amenkov at openjdk.org  Tue Jun 27 20:54:27 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 27 Jun 2023 20:54:27 GMT
Subject: RFR: JDK-8310066: Improve test coverage for JVMTI GetThreadState
 on carrier and mounted vthread [v2]
In-Reply-To: <_8UnxXrT842BKmJ98GlmJyL21yzM0dhGOkeeK0Mnf2g=.c90b2826-922c-4838-b816-8bf3b5933d87@github.com>
References: <_8UnxXrT842BKmJ98GlmJyL21yzM0dhGOkeeK0Mnf2g=.c90b2826-922c-4838-b816-8bf3b5933d87@github.com>
Message-ID: <WeG8y6Wt96LudgWu0cLSDXiMl8WYFdvihb8hiVDNbK8=.7a75ef50-73ea-4380-a58a-7c3f1b8ec52a@github.com>

> This is follow-up JDK-8307153/JDK-8309612 (JVMTI GetThreadState on carrier should return STATE_WAITING)
> New test tests GetThreadState for different thread states.
> The test detected a bug in the implementation, new issue is created: JDK-8310584
> Corresponding testcases are commented now in the test, fix for JDK-8310584 will uncomment them

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  Added spaces in synchronized

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14622/files
  - new: https://git.openjdk.org/jdk/pull/14622/files/c5f669b7..b5b39bcd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14622&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14622&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14622.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14622/head:pull/14622

PR: https://git.openjdk.org/jdk/pull/14622

From dnsimon at openjdk.org  Tue Jun 27 21:29:53 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 27 Jun 2023 21:29:53 GMT
Subject: RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit [v4]
In-Reply-To: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
References: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
Message-ID: <bR9LN8hNjz3yHo9L_bh-0Q0j778pDnRKV9pmclEiYko=.5cb5fae1-131e-4845-bdb8-cbd55f5655c0@github.com>

> The VMSupport class is required for translating an exception between the HotSpot and libgraal heaps.
> Loading it lazily can result in a loading exception, obscuring the exception being translated.
> To avoid this, VMSupport is loaded eagerly along with the other vmClasses.

Doug Simon has updated the pull request incrementally with one additional commit since the last revision:

  revert to lazy loading of VMSupport

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14641/files
  - new: https://git.openjdk.org/jdk/pull/14641/files/819a24fd..734903a8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14641&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14641&range=02-03

  Stats: 35 lines in 5 files changed: 17 ins; 2 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/14641.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14641/head:pull/14641

PR: https://git.openjdk.org/jdk/pull/14641

From dnsimon at openjdk.org  Tue Jun 27 21:30:14 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Tue, 27 Jun 2023 21:30:14 GMT
Subject: RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit [v3]
In-Reply-To: <bY4wAhAD6sOLr0zuHQJ6tMkD6shiL4RwnL7kIxk91YI=.03848181-fa09-4988-bd9d-7d0dc4e85d49@github.com>
References: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
 <bY4wAhAD6sOLr0zuHQJ6tMkD6shiL4RwnL7kIxk91YI=.03848181-fa09-4988-bd9d-7d0dc4e85d49@github.com>
Message-ID: <biIW3jiJSNeDI5tdhXVTie6XkHvG5-z7YDKWR66ljw4=.74890ff4-6ecb-4b0d-a038-8ef016108b46@github.com>

On Mon, 26 Jun 2023 13:17:25 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> The VMSupport class is required for translating an exception between the HotSpot and libgraal heaps.
>> Loading it lazily can result in a loading exception, obscuring the exception being translated.
>> To avoid this, VMSupport is loaded eagerly along with the other vmClasses.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   each exception translation failure should trigger a JVMCI event

I've pushed the loading of `VMSupport` down into the 2 cases where it's actually needed and made it lazy again which should address all concerns about extra noise at VM startup. Thanks for the push back on this - I agree that it's the best solution.

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

PR Comment: https://git.openjdk.org/jdk/pull/14641#issuecomment-1610243648

From amenkov at openjdk.org  Tue Jun 27 22:11:07 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 27 Jun 2023 22:11:07 GMT
Subject: RFR: JDK-8310066: Improve test coverage for JVMTI GetThreadState
 on carrier and mounted vthread [v2]
In-Reply-To: <z2rrNBxFLFqhYKY_UMYK-qfucI6w9hkgnZLz80Naujg=.cec0551d-3d7f-4a78-bba1-5a61d3665900@github.com>
References: <_8UnxXrT842BKmJ98GlmJyL21yzM0dhGOkeeK0Mnf2g=.c90b2826-922c-4838-b816-8bf3b5933d87@github.com>
 <z2rrNBxFLFqhYKY_UMYK-qfucI6w9hkgnZLz80Naujg=.cec0551d-3d7f-4a78-bba1-5a61d3665900@github.com>
Message-ID: <zDCXLaHZQhMZ6KRDC4U8OzOdnk4-zuhuVuaIMwFL_Ak=.0ec6ef5b-e663-4158-a93e-be416eea98cb@github.com>

On Mon, 26 Jun 2023 20:57:44 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added spaces in synchronized
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadStateMountedTest/GetThreadStateMountedTest.java line 85:
> 
>> 83:             }
>> 84:         });
>> 85:         synchronized(syncObj) {
> 
> Suggestion:
> 
>         synchronized (syncObj) {

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14622#discussion_r1244420236

From coleenp at openjdk.org  Tue Jun 27 23:03:03 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 27 Jun 2023 23:03:03 GMT
Subject: RFR: 8310906: Fix -Wconversion warnings in runtime,
 oops and some code header files. [v3]
In-Reply-To: <nY6ZCwe0ts6wSaUCDJb0LFVsMXmMCpV_tE-XVZOibc0=.9d5802cb-edd3-4c36-93e5-4c19da5d2cc3@github.com>
References: <hvRAKRMNH1sBjeP5Ikhc5zt-4uyasNOEQ9Z0AeQbyAA=.64bdd842-d4b6-420d-a4e2-409567eb66b1@github.com>
 <nY6ZCwe0ts6wSaUCDJb0LFVsMXmMCpV_tE-XVZOibc0=.9d5802cb-edd3-4c36-93e5-4c19da5d2cc3@github.com>
Message-ID: <kLJB4ruYOvjdPOdfCYqAuxIiB0g9zyk0uGEYX3q1H3w=.7e744c29-a3c8-4ff1-80e5-edbdefd125be@github.com>

On Tue, 27 Jun 2023 20:48:27 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is another version of PR https://github.com/openjdk/jdk/pull/14659 but I've added a pointer delta function in globalDefinitions.hpp to use for these pointer diff calculations that return int everywhere.  If the name is agreeable, I'll fix the other cases of this like this.  It's better than raw casts.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed the comment.

delta_as_int() could also be: delta2int()  ptrdelta2int() ptrdiff2int() ptrsub2int() in the theme of shorter names.
pointer_delta_as_int() ignoring it does something different than pointer_delta() (allows negative returns).
Change them all to check_cast<int>(a - b) - losing identifiable name
ptrdiff_cast(a - b) where int ptrdiff_cast(ptrdiff_t val) { return check<cast>(val); }

Brainstorming in a PR.  Your suggestions welcome.

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

PR Comment: https://git.openjdk.org/jdk/pull/14675#issuecomment-1610330128

From never at openjdk.org  Tue Jun 27 23:11:05 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Tue, 27 Jun 2023 23:11:05 GMT
Subject: RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit [v4]
In-Reply-To: <bR9LN8hNjz3yHo9L_bh-0Q0j778pDnRKV9pmclEiYko=.5cb5fae1-131e-4845-bdb8-cbd55f5655c0@github.com>
References: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
 <bR9LN8hNjz3yHo9L_bh-0Q0j778pDnRKV9pmclEiYko=.5cb5fae1-131e-4845-bdb8-cbd55f5655c0@github.com>
Message-ID: <D3DWMTkjn8Ri5X23oIM0tBUES6rPSyEEPYac4rpcxUQ=.5090d6d8-6589-4644-bd67-920a26e48462@github.com>

On Tue, 27 Jun 2023 21:29:53 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> The VMSupport class is required for translating an exception between the HotSpot and libgraal heaps.
>> Loading it lazily can result in a loading exception, obscuring the exception being translated.
>> To avoid this, VMSupport is loaded eagerly along with the other vmClasses.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert to lazy loading of VMSupport

I don't think pushing it down that far improves things.  encode always precedes decode so why not resolve it before the encode call.

      // Resolve VMSupport class explicitly as HotSpotJVMCI::compute_offsets
      // may not have been called.
      Klass* vmSupport = SystemDictionary::resolve_or_fail(vmSymbols::jdk_internal_vm_VMSupport(), true, THREAD);
      int res = 0;
      if (!HAS_PENDING_EXCEPTION) {
        res = encode(THREAD, vmSupport, buffer, buffer_size);
      }

src/hotspot/share/jvmci/jvmciEnv.cpp line 402:

> 400:       }
> 401:       int res = encode(THREAD, buffer, buffer_size);
> 402:       if (_from_env != nullptr && !_from_env->is_hotspot() && _from_env->has_pending_exception()) {

Why is this check before the `HAS_PENDING_EXCEPTION` check?  Couldn't you end up returning with a pending exception in this path?

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

PR Comment: https://git.openjdk.org/jdk/pull/14641#issuecomment-1610335668
PR Review Comment: https://git.openjdk.org/jdk/pull/14641#discussion_r1244461845

From mbaesken at openjdk.org  Wed Jun 28 06:54:15 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 28 Jun 2023 06:54:15 GMT
Subject: RFR: JDK-8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work [v4]
In-Reply-To: <tdhFvurYKJgIVFAThJ7bZzFgVGR2VWsUnmye2-ZZT8Q=.b56d19ad-1efd-4896-b576-44c315465578@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
 <tdhFvurYKJgIVFAThJ7bZzFgVGR2VWsUnmye2-ZZT8Q=.b56d19ad-1efd-4896-b576-44c315465578@github.com>
Message-ID: <C2-UUagDxny8B77nO8DEXjvUjU3jihIdw-0WlBc3ESE=.2b1d572f-2da4-4c2e-896a-317d7b20b303@github.com>

On Tue, 27 Jun 2023 13:45:27 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
>> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
>> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
>> But without the entitlement, a core is not generated.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   small adjustments

Thanks for the review !

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

PR Comment: https://git.openjdk.org/jdk/pull/14562#issuecomment-1610866191

From mbaesken at openjdk.org  Wed Jun 28 06:54:16 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 28 Jun 2023 06:54:16 GMT
Subject: Integrated: JDK-8310380: Handle problems in core-related tests on
 macOS when codesign tool does not work
In-Reply-To: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
References: <zelXPXxv73lUhS-8PD3ERxqFUlgwhdN32DeYzYYoffU=.ba1e02cd-7eae-4783-a383-12f6f090beb5@github.com>
Message-ID: <_kf3OJmeEyW36gl2VpVoCiPuOUubkqc-u07Ht7SSxnw=.b841cf2f-3440-4f4a-975c-ae01644dc67f@github.com>

On Tue, 20 Jun 2023 13:23:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently, a number of tests fail on macOS because they miss the core file (e.g. serviceability/sa/TestJmapCore.java).
> The reason is that configure detects on some setups that codesign does not work ("checking if debug mode codesign is possible... no) .
> So adding the needed entitlement to generate cores is not done in the build. This is currently not checked later in the tests.
> But without the entitlement, a core is not generated.

This pull request has now been integrated.

Changeset: 39c104df
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/39c104df44f17c1d65e35becd4272f73e2c6610c
Stats:     56 lines in 4 files changed: 37 ins; 12 del; 7 mod

8310380: Handle problems in core-related tests on macOS when codesign tool does not work

Reviewed-by: lucy, clanger, cjplummer

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

PR: https://git.openjdk.org/jdk/pull/14562

From liach at openjdk.org  Wed Jun 28 07:02:17 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 28 Jun 2023 07:02:17 GMT
Subject: RFR: 8294977: Convert test/jdk/java tests from ASM library to
 Classfile API [v9]
In-Reply-To: <ZNm0kG5HiHCfixYeCz0EGjsT7ejmvPsXxN36-vAwQsU=.3eec9170-96da-444e-ad10-0095597b4fef@github.com>
References: <ZNm0kG5HiHCfixYeCz0EGjsT7ejmvPsXxN36-vAwQsU=.3eec9170-96da-444e-ad10-0095597b4fef@github.com>
Message-ID: <nUxCWqXBbfxXKWnOpQ9aEqXAz3GInytnmLBi_pSnsqI=.8ccaf3ed-426b-4859-82ac-66e06243c09f@github.com>

> Summaries:
> 1. A few recommendations about updating the constant API is made at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html and I may update this patch shall the API changes be integrated before
> 2. One ASM library-specific test, `LambdaAsm` is removed. Others have their code generation infrastructure upgraded from ASM to Classfile API.
> 3. Most tests are included in tier1, but some are not:
> In `:jdk_io`: (tier2, part 2)
> 
> test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java
> test/jdk/java/io/Serializable/records/ProhibitedMethods.java
> test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java
> 
> In `:jdk_instrument`: (tier 3)
> 
> test/jdk/java/lang/instrument/RetransformAgent.java
> test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java
> test/jdk/java/lang/instrument/asmlib/Instrumentor.java
> 
> 
> @asotona Would you mind reviewing?

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Classfile object update
 - Merge branch 'master' into invoke-test-classfile
 - Merge branch 'master' into invoke-test-classfile
 - Switch to ConstantDescs for <init> <clinit> and void constants
 - Merge AnnotationsTest, remove ModuleTargetAttribute call
 - Merge branch 'invoke-test-classfile' of https://github.com/liachmodded/jdk into invoke-test-classfile
 - Update test/jdk/java/lang/invoke/8022701/MHIllegalAccess.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Merge branch 'master' into invoke-test-classfile
 - Fix LambdaStackTrace after running
 - formatting
 - ... and 4 more: https://git.openjdk.org/jdk/compare/526dba1a...d0b6c2ae

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

Changes: https://git.openjdk.org/jdk/pull/13009/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13009&range=08
  Stats: 1954 lines in 31 files changed: 307 ins; 883 del; 764 mod
  Patch: https://git.openjdk.org/jdk/pull/13009.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13009/head:pull/13009

PR: https://git.openjdk.org/jdk/pull/13009

From dnsimon at openjdk.org  Wed Jun 28 07:22:05 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 28 Jun 2023 07:22:05 GMT
Subject: RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit [v4]
In-Reply-To: <D3DWMTkjn8Ri5X23oIM0tBUES6rPSyEEPYac4rpcxUQ=.5090d6d8-6589-4644-bd67-920a26e48462@github.com>
References: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
 <bR9LN8hNjz3yHo9L_bh-0Q0j778pDnRKV9pmclEiYko=.5cb5fae1-131e-4845-bdb8-cbd55f5655c0@github.com>
 <D3DWMTkjn8Ri5X23oIM0tBUES6rPSyEEPYac4rpcxUQ=.5090d6d8-6589-4644-bd67-920a26e48462@github.com>
Message-ID: <hBxgIVYTbl-PzyfBXhJb7_U9oefzVo1eePD4BfXVHF4=.100257e5-82dd-4f20-a3f4-6f3fad01cfce@github.com>

On Tue, 27 Jun 2023 23:08:22 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert to lazy loading of VMSupport
>
> src/hotspot/share/jvmci/jvmciEnv.cpp line 402:
> 
>> 400:       }
>> 401:       int res = encode(THREAD, buffer, buffer_size);
>> 402:       if (_from_env != nullptr && !_from_env->is_hotspot() && _from_env->has_pending_exception()) {
> 
> Why is this check before the `HAS_PENDING_EXCEPTION` check?  Couldn't you end up returning with a pending exception in this path?

If `encode` is `SharedLibraryToHotSpotExceptionTranslation::encode` there is no possibility of a pending HotSpot exception upon it returning. If it's `HotSpotToSharedLibraryExceptionTranslation::encode` then `_from_env->is_hotspot()` is `true` and so this `if` branch is not taken.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14641#discussion_r1244794019

From dnsimon at openjdk.org  Wed Jun 28 07:26:07 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 28 Jun 2023 07:26:07 GMT
Subject: RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit [v4]
In-Reply-To: <D3DWMTkjn8Ri5X23oIM0tBUES6rPSyEEPYac4rpcxUQ=.5090d6d8-6589-4644-bd67-920a26e48462@github.com>
References: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
 <bR9LN8hNjz3yHo9L_bh-0Q0j778pDnRKV9pmclEiYko=.5cb5fae1-131e-4845-bdb8-cbd55f5655c0@github.com>
 <D3DWMTkjn8Ri5X23oIM0tBUES6rPSyEEPYac4rpcxUQ=.5090d6d8-6589-4644-bd67-920a26e48462@github.com>
Message-ID: <FAr5ktmiqzbQ_boxBSGl4IxuMNzem8wljkhjTm_Vjc0=.7e19d335-32d7-4b24-9644-450a4b27fd2e@github.com>

On Tue, 27 Jun 2023 23:06:49 GMT, Tom Rodriguez <never at openjdk.org> wrote:

> I don't think pushing it down that far improves things. encode always precedes decode so why not resolve it before the encode call.

Because the `VMSupport` klass is only needed if calling into HotSpot so it's better to push it down into `HotSpotToSharedLibraryExceptionTranslation::encode`. Also, if the `VMSupport` klass is used for encoding, it's *not* needed for decoding (the libgraal `VMSupport` jclass value is used instead).

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

PR Comment: https://git.openjdk.org/jdk/pull/14641#issuecomment-1610903263

From sspitsyn at openjdk.org  Wed Jun 28 07:40:11 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 28 Jun 2023 07:40:11 GMT
Subject: RFR: JDK-8310066: Improve test coverage for JVMTI GetThreadState
 on carrier and mounted vthread [v2]
In-Reply-To: <WeG8y6Wt96LudgWu0cLSDXiMl8WYFdvihb8hiVDNbK8=.7a75ef50-73ea-4380-a58a-7c3f1b8ec52a@github.com>
References: <_8UnxXrT842BKmJ98GlmJyL21yzM0dhGOkeeK0Mnf2g=.c90b2826-922c-4838-b816-8bf3b5933d87@github.com>
 <WeG8y6Wt96LudgWu0cLSDXiMl8WYFdvihb8hiVDNbK8=.7a75ef50-73ea-4380-a58a-7c3f1b8ec52a@github.com>
Message-ID: <q9qTVfusiKqVeyY-kv9K7TdzJGEhcv8I9pmjTNjHqC4=.8ada8f11-d647-4189-ace4-7788c0a4eae4@github.com>

On Tue, 27 Jun 2023 20:54:27 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> This is follow-up JDK-8307153/JDK-8309612 (JVMTI GetThreadState on carrier should return STATE_WAITING)
>> New test tests GetThreadState for different thread states.
>> The test detected a bug in the implementation, new issue is created: JDK-8310584
>> Corresponding testcases are commented now in the test, fix for JDK-8310584 will uncomment them
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added spaces in synchronized

The test is great.
I realize it is not easy to make it fully reliable though.
So, will need another pass.

test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadStateMountedTest/GetThreadStateMountedTest.java line 117:

> 115:                 } catch (InterruptedException ex) {
> 116:                     // expected, ignore
> 117:                 }

Shout this code account for spurious wakeups?

test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadStateMountedTest/GetThreadStateMountedTest.java line 241:

> 239:     private static native void waitInNative();
> 240:     // Signals waitInNative() to exit.
> 241:     private static native void endWait();

Q: Where is this native method invoked?

test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadStateMountedTest/libGetThreadStateMountedTest.cpp line 73:

> 71:     jint unexpected = state - actual_full;
> 72:     LOG("  ERROR: some unexpected bits are set (%x): %s\n",
> 73:        unexpected, TranslateState(unexpected));

Nit: lines 65, 73 have wrong indent.

test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadStateMountedTest/libGetThreadStateMountedTest.cpp line 176:

> 174:   while (!time_to_exit) {
> 175:     sleep_ms(100);
> 176:   }

Is this loop reliable in terms of thread states?

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

PR Review: https://git.openjdk.org/jdk/pull/14622#pullrequestreview-1502440716
PR Review Comment: https://git.openjdk.org/jdk/pull/14622#discussion_r1244797022
PR Review Comment: https://git.openjdk.org/jdk/pull/14622#discussion_r1244791733
PR Review Comment: https://git.openjdk.org/jdk/pull/14622#discussion_r1244809438
PR Review Comment: https://git.openjdk.org/jdk/pull/14622#discussion_r1244799190

From stefank at openjdk.org  Wed Jun 28 07:56:06 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 28 Jun 2023 07:56:06 GMT
Subject: RFR: 8310906: Fix -Wconversion warnings in runtime,
 oops and some code header files. [v3]
In-Reply-To: <c2RZS7gtSPZJzchcDSd5IOAkTMRag-F3JHOTpLOIBzc=.09b3bbad-2587-45cc-8d7b-a6b540994549@github.com>
References: <hvRAKRMNH1sBjeP5Ikhc5zt-4uyasNOEQ9Z0AeQbyAA=.64bdd842-d4b6-420d-a4e2-409567eb66b1@github.com>
 <L3kD9sU0DxRbVwVhIMQMo3GXFnAx-N7hiOs94cxufQM=.c8b482e4-a1a1-4148-87c4-ab8a4cc7424b@github.com>
 <7jCGpmw9yQYwUzVAR8Ytaj3TiUWSFOscyMlkkg4Abvs=.f6f65abf-b3f3-4718-87b6-d0c78d82038d@github.com>
 <c2RZS7gtSPZJzchcDSd5IOAkTMRag-F3JHOTpLOIBzc=.09b3bbad-2587-45cc-8d7b-a6b540994549@github.com>
Message-ID: <WNMlOyhe1wsa8GU0SmlwiD8zgk8U3GyGU0H9n3U67OE=.c8f2fb90-a418-4163-8b4b-d27541c4f7cd@github.com>

On Tue, 27 Jun 2023 15:11:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Hm.  Maybe this would be ok. Our original idea was to make it T* not T until this cast.  I don't know how many other cases there are that I haven't gotten to yet.  But it would eliminate a cast, so that's good (unless these aren't the same).  Some instances have ptr - constant that gets promoted I think.
>> The reason we didn't pick pointer_delta_as_int because pointer_delta has different semantics.  pointer_delta insists on positive results.
>
> Taking out that cast does work, so I've fixed that.

> pointer_delta has different semantics

Right. That was "recently" added to pointer_delta with JDK-8260046. It begs the question why felt the need to add it there but feel that it is OK to skip it for delta_as_int? Is there some usage of delta_as_int that gives back negative values? Could that call site be changed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14675#discussion_r1244829942

From yyang at openjdk.org  Wed Jun 28 08:04:21 2023
From: yyang at openjdk.org (Yi Yang)
Date: Wed, 28 Jun 2023 08:04:21 GMT
Subject: RFR: JDK-8306441: Two-stage Segmented Heap Dump [v14]
In-Reply-To: <8YqPPHSW4K1s0t317Kp6UqvoGuv5v9oCbjtQ9FX8p2o=.0f6c687b-d031-401d-901d-1ec532715cdc@github.com>
References: <8YqPPHSW4K1s0t317Kp6UqvoGuv5v9oCbjtQ9FX8p2o=.0f6c687b-d031-401d-901d-1ec532715cdc@github.com>
Message-ID: <5E3RXGlOAWHiPX69pYfbNt8qMfFrHEw0qgtuh4AOmFI=.f8622edb-61fd-430e-9287-2dc864e4e038@github.com>

> ### Motivation and proposal
> Hi, heap dump brings about pauses for application's execution(STW), this is a well-known pain. JDK-8252842 have added parallel support to heapdump in an attempt to alleviate this issue. However, all concurrent threads competitively write heap data to the same file, and more memory is required to maintain the concurrent buffer queue. In experiments, we did not feel a significant performance improvement from that.
> 
> The minor-pause solution, which is presented in this PR, is a two-stage segmented heap dump:
> 
> 1. Stage One(STW): Concurrent threads directly write data to multiple heap files.
> 2. Stage Two(Non-STW): Merge multiple heap files into one complete heap dump file.
> 
> Now concurrent worker threads are not required to maintain a buffer queue, which would result in more memory overhead, nor do they need to compete for locks. The changes in the overall design are as follows:
> 
> ![image](https://github.com/openjdk/jdk/assets/5010047/86d2717d-c621-446f-98c2-cce761ec8db5)
> <p align="center">Fig1. Before</p>
> 
> ![image](https://github.com/openjdk/jdk/assets/5010047/c912c516-83b6-4343-a2e8-5d5bdb99cb87)
> <p align="center">Fig1. After this patch</p>
> 
> ### Performance evaluation
> | memory | numOfThread | STW         | Total      | Compression |
> | --- | --------- | -------------- | ------------ | -------- |
> | 8g | 1 thread | 15.612 secs | 15.612 secs | N |
> | 8g | 32 thread |  2.5617250 secs | 14.498 secs | N |
> | 8g | 32 thread | 2.3084878 secs | 3.198 secs | Compress1 |
> | 8g | 32 thread | 10.9355128 secs | 21.882 secs | Compress2 |
> | 8g | 96 thread | 2.6790452 secs | 14.012 secs | N |
> | 8g | 96 thread | 2.3044796 secs | 3.589 secs | Compress1 |
> | 8g | 96 thread | 9.7585151 secs | 20.219 secs| Compress2 |
> | 16g | 1 thread | 26.278 secs | 26.278 secs | N |
> | 16g | 32 thread |  5.2313740 secs | 26.417 secs | N |
> | 16g | 32 thread | 5.6946983 secs | 6.538 secs | Compress1 |
> | 16g | 32 thread | 21.8211105 secs | 41.133 secs | Compress2 |
> | 16g | 96 thread | 6.2445556 secs | 27.141 secs | N |
> | 16g | 96 thread | 4.6007096 secs | 6.259 secs | Compress1 |
> | 16g | 96 thread | 19.2965783 secs |  39.007 secs | Compress2 |
> | 32g | 1 thread | 48.149 secs | 48.149 secs | N |
> | 32g | 32 thread | 10.7734677 secs | 61.643 secs | N |
> | 32g | 32 thread | 10.1642097 secs | 10.903 secs | Compress1 |
> | 32g | 32 thread | 43.8407607 secs | 88.152 secs | Compress2 |
> | 32g | 96 thread | 13.1522042 secs | 61.432 secs | N |
> | 32g | 96 thread | 9.0954641 secs | 9.885 secs | C...

Yi Yang has updated the pull request incrementally with one additional commit since the last revision:

  memory leak

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13667/files
  - new: https://git.openjdk.org/jdk/pull/13667/files/ecab3116..2012b5ca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13667&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13667&range=12-13

  Stats: 52 lines in 1 file changed: 22 ins; 13 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/13667.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13667/head:pull/13667

PR: https://git.openjdk.org/jdk/pull/13667

From yyang at openjdk.org  Wed Jun 28 08:04:21 2023
From: yyang at openjdk.org (Yi Yang)
Date: Wed, 28 Jun 2023 08:04:21 GMT
Subject: RFR: JDK-8306441: Two-stage Segmented Heap Dump [v5]
In-Reply-To: <ND9kZgFWcpvUXuGAvet3P_ZogisHGeBtlp25Bs0yq54=.40f4bb74-860e-4da4-8fcb-219a9f8d1268@github.com>
References: <8YqPPHSW4K1s0t317Kp6UqvoGuv5v9oCbjtQ9FX8p2o=.0f6c687b-d031-401d-901d-1ec532715cdc@github.com>
 <wNQyKkNDDiJASas3cYcqFnivt88Zx75VSMxr4YWeUwE=.751ca007-5117-4bb1-aacf-561498d6f5f8@github.com>
 <P16t1xi9eYl0bNjMUlxj9RJ-Qc4n9wnAmOMGWm-akwY=.93176665-7be1-48d5-826f-cc3e3a8f63ce@github.com>
 <ND9kZgFWcpvUXuGAvet3P_ZogisHGeBtlp25Bs0yq54=.40f4bb74-860e-4da4-8fcb-219a9f8d1268@github.com>
Message-ID: <8myxOD2ESz_csHwacR0SK4fssfmtCigv_y7rrpY1gOE=.04950fcd-648a-43ef-bb3b-178c7c266adc@github.com>

On Tue, 16 May 2023 18:41:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Hi, can I have a review for this patch?
>
> @y1yang0 Sorry no one has been able to review this so far. The serviceability team is very busy for the next few weeks finishing up JDK 21 changes before RDP1. It's unlikely we'll find time for the review before them.
> 
> I did take a very quick look at the changes just to understand the scope. One thing I noticed that makes this PR hard to review is the code refactoring and relocating that you did. At first it looks like a lot of old code was deleted and a lot of new code added, but in fact most of the new code is just relocated old code. It makes it very hard to tell if there have been any changes to this code. Is there anything you can do to lessen the amount of apparent new code that is actually just moved code?

Hi @plummercj @kevinjwalls @alexmenkov   do you have any plans to review this patch recently? I have addressed some bugs and it passed manual tests& all jtreg tests.

Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/13667#issuecomment-1610946603

From kevinw at openjdk.org  Wed Jun 28 08:33:13 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 28 Jun 2023 08:33:13 GMT
Subject: [jdk21] Integrated: 8303916: ThreadLists.java inconsistent results
In-Reply-To: <EM-gSGWADuTyVdSaS_8MNv8pMUUGz6JRFidTnHww304=.8747b919-93e6-46ef-aac9-0da01c80033b@github.com>
References: <EM-gSGWADuTyVdSaS_8MNv8pMUUGz6JRFidTnHww304=.8747b919-93e6-46ef-aac9-0da01c80033b@github.com>
Message-ID: <nu4KSEDV4T0KhARDgSJYcGhqXuo7sWuficUid4qcPNg=.582864b8-2fc0-4b7b-be46-bdacb53c9cd5@github.com>

On Fri, 16 Jun 2023 09:15:52 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Clean backport from latest jdk repo to jdk21 for the test change:
> 8303916: ThreadLists.java inconsistent results

This pull request has now been integrated.

Changeset: 8d9ebb69
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/8d9ebb6981a163a7c223eff154eb5ad966e146f1
Stats:     77 lines in 1 file changed: 54 ins; 1 del; 22 mod

8303916: ThreadLists.java inconsistent results

Reviewed-by: sspitsyn
Backport-of: 8c9b85a990d955487f9141207cc83d0051defc57

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

PR: https://git.openjdk.org/jdk21/pull/24

From dholmes at openjdk.org  Wed Jun 28 12:22:02 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 28 Jun 2023 12:22:02 GMT
Subject: RFR: 8310948: Fix ignored-qualifiers warning in Hotspot
In-Reply-To: <hNI7tUjnrrsVnOlgJUzzLywNXljokcIjUBuH3DgtHdE=.f26e72bb-591f-48f1-8dfe-f4c85254b72f@github.com>
References: <hNI7tUjnrrsVnOlgJUzzLywNXljokcIjUBuH3DgtHdE=.f26e72bb-591f-48f1-8dfe-f4c85254b72f@github.com>
Message-ID: <uJuWnnJqqZG1wbUGrLLAO1i6uxQcwrze4ntJShGNcSA=.927ca2d9-dfd6-4629-9c7e-4a0e388704ec@github.com>

On Tue, 27 Jun 2023 12:22:43 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> warning: 'volatile' type qualifier on return type has no effect

Can't say that I understand that warning. If I pass in a volatile pointer and return the same pointer then I would not expect to lose the volatile aspect of it. @kbarrett can you explain this one to me?

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

PR Comment: https://git.openjdk.org/jdk/pull/14674#issuecomment-1611299893

From coleenp at openjdk.org  Wed Jun 28 12:37:04 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 28 Jun 2023 12:37:04 GMT
Subject: RFR: 8310906: Fix -Wconversion warnings in runtime,
 oops and some code header files. [v3]
In-Reply-To: <WNMlOyhe1wsa8GU0SmlwiD8zgk8U3GyGU0H9n3U67OE=.c8f2fb90-a418-4163-8b4b-d27541c4f7cd@github.com>
References: <hvRAKRMNH1sBjeP5Ikhc5zt-4uyasNOEQ9Z0AeQbyAA=.64bdd842-d4b6-420d-a4e2-409567eb66b1@github.com>
 <L3kD9sU0DxRbVwVhIMQMo3GXFnAx-N7hiOs94cxufQM=.c8b482e4-a1a1-4148-87c4-ab8a4cc7424b@github.com>
 <7jCGpmw9yQYwUzVAR8Ytaj3TiUWSFOscyMlkkg4Abvs=.f6f65abf-b3f3-4718-87b6-d0c78d82038d@github.com>
 <c2RZS7gtSPZJzchcDSd5IOAkTMRag-F3JHOTpLOIBzc=.09b3bbad-2587-45cc-8d7b-a6b540994549@github.com>
 <WNMlOyhe1wsa8GU0SmlwiD8zgk8U3GyGU0H9n3U67OE=.c8f2fb90-a418-4163-8b4b-d27541c4f7cd@github.com>
Message-ID: <V5-a9HHvwBiKlFbta7O5uubx5DjstZtNDiX4T3ywl50=.29ef6ec5-c501-41bc-9c03-6f12d361296d@github.com>

On Wed, 28 Jun 2023 07:52:35 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Taking out that cast does work, so I've fixed that.
>
>> pointer_delta has different semantics
> 
> Right. That was "recently" added to pointer_delta with JDK-8260046. It begs the question why felt the need to add it there but feel that it is OK to skip it for delta_as_int? Is there some usage of delta_as_int that gives back negative values? Could that call site be changed?

There are sites where the result is negative but this is a good suggestion because it makes the name more consistent.  I can change those to plain check_cast<int>s.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14675#discussion_r1245141370

From mbaesken at openjdk.org  Wed Jun 28 12:57:07 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 28 Jun 2023 12:57:07 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar
In-Reply-To: <CXXV_lxlp7_Ntc0hbwPmVezF5PNqfm3oQpiY4HLl6TE=.a8b48f90-8e50-4022-9280-2e54933289a9@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
 <CXXV_lxlp7_Ntc0hbwPmVezF5PNqfm3oQpiY4HLl6TE=.a8b48f90-8e50-4022-9280-2e54933289a9@github.com>
Message-ID: <fZt11UIM3a4eNOSEVvv-KLEYE1pVLbz_hH_ifk9U-18=.e89142c9-ccd1-4ea5-81d5-97f0eb58d54d@github.com>

On Thu, 22 Jun 2023 14:20:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted.
>
> src/java.sql/share/classes/java/sql/DriverManager.java line 658:
> 
>> 656:          * (which is invoking this class indirectly)
>> 657:          * classloader, so that the JDBC driver class outside the image
>> 658:          * can be loaded from here.
> 
> This code should probably be changed to use VM.isSystemDomainLoader(callerCL).
> 
> I think the comment should be replaced because it doesn't match what it actually does and it's nothing to do with the whether the JDBC driver is in the run-time image or not. How about:
> 
> "If the caller is defined to the bootstrap or platform class loader then use the Thread CCL as the initiating class loader so that a JDBC on the class path, or bundled with an application, is found."

Hi Alan, regarding usage of class VM I get 
'package jdk.internal.misc is declared in module java.base, which does not export it to module java.sql'
Is there any concern to export it as well to module java.sql  ?
And btw did you mean to use it like this, in the if  ?

`        if (callerCL == null || VM.isSystemDomainLoader(callerCL)) {
            callerCL = Thread.currentThread().getContextClassLoader();
        }`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1245164604

From coleenp at openjdk.org  Wed Jun 28 13:17:21 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 28 Jun 2023 13:17:21 GMT
Subject: RFR: 8310906: Fix -Wconversion warnings in runtime,
 oops and some code header files. [v4]
In-Reply-To: <hvRAKRMNH1sBjeP5Ikhc5zt-4uyasNOEQ9Z0AeQbyAA=.64bdd842-d4b6-420d-a4e2-409567eb66b1@github.com>
References: <hvRAKRMNH1sBjeP5Ikhc5zt-4uyasNOEQ9Z0AeQbyAA=.64bdd842-d4b6-420d-a4e2-409567eb66b1@github.com>
Message-ID: <2_AcdyIbMgXJp3ZmG7_O62U8Qhj1DDxUI41rWlpRkPI=.8863835b-faf8-4f3d-a933-d59b0c6e6f95@github.com>

> This is another version of PR https://github.com/openjdk/jdk/pull/14659 but I've added a pointer delta function in globalDefinitions.hpp to use for these pointer diff calculations that return int everywhere.  If the name is agreeable, I'll fix the other cases of this like this.  It's better than raw casts.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Use pointer_delta_as_int for the name that uses pointer_delta, fix negative case to just do checked_cast.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14675/files
  - new: https://git.openjdk.org/jdk/pull/14675/files/858e9cfb..9fed8c89

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14675&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14675&range=02-03

  Stats: 22 lines in 14 files changed: 0 ins; 1 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/14675.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14675/head:pull/14675

PR: https://git.openjdk.org/jdk/pull/14675

From alanb at openjdk.org  Wed Jun 28 13:19:03 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 28 Jun 2023 13:19:03 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar
In-Reply-To: <fZt11UIM3a4eNOSEVvv-KLEYE1pVLbz_hH_ifk9U-18=.e89142c9-ccd1-4ea5-81d5-97f0eb58d54d@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
 <CXXV_lxlp7_Ntc0hbwPmVezF5PNqfm3oQpiY4HLl6TE=.a8b48f90-8e50-4022-9280-2e54933289a9@github.com>
 <fZt11UIM3a4eNOSEVvv-KLEYE1pVLbz_hH_ifk9U-18=.e89142c9-ccd1-4ea5-81d5-97f0eb58d54d@github.com>
Message-ID: <WbcMqs8LKR8wh3khpe0EY_O4A6XEHblMsd9lmqvfUVQ=.a5db7b5c-00f2-4ea2-a5e8-4fcf893739b5@github.com>

On Wed, 28 Jun 2023 12:54:10 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi Alan, regarding usage of class VM I get 'package jdk.internal.misc is declared in module java.base, which does not export it to module java.sql' Is there any concern to export it as well to module java.sql ? And btw did you mean to use it like this, in the if ?
> 
> `if (callerCL == null || VM.isSystemDomainLoader(callerCL)) { callerCL = Thread.currentThread().getContextClassLoader(); }`

It was just a passing comment, I didn't meant to suggest changing it as part of this PR. We have always think twice before adding qualified exports from java.base and this is case where java.sql is very "non-core", we don't want to give it any access to java.base internals.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1245197137

From mbaesken at openjdk.org  Wed Jun 28 13:25:07 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 28 Jun 2023 13:25:07 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar
In-Reply-To: <WbcMqs8LKR8wh3khpe0EY_O4A6XEHblMsd9lmqvfUVQ=.a5db7b5c-00f2-4ea2-a5e8-4fcf893739b5@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
 <CXXV_lxlp7_Ntc0hbwPmVezF5PNqfm3oQpiY4HLl6TE=.a8b48f90-8e50-4022-9280-2e54933289a9@github.com>
 <fZt11UIM3a4eNOSEVvv-KLEYE1pVLbz_hH_ifk9U-18=.e89142c9-ccd1-4ea5-81d5-97f0eb58d54d@github.com>
 <WbcMqs8LKR8wh3khpe0EY_O4A6XEHblMsd9lmqvfUVQ=.a5db7b5c-00f2-4ea2-a5e8-4fcf893739b5@github.com>
Message-ID: <hduIpeINBeZIgNUPt5qs_TdEG3pTXUdwCxxvIGmpb_k=.6c25d0fc-da5f-4a41-b21d-ce415d6153d0@github.com>

On Wed, 28 Jun 2023 13:16:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi Alan, regarding usage of class VM I get 
>> 'package jdk.internal.misc is declared in module java.base, which does not export it to module java.sql'
>> Is there any concern to export it as well to module java.sql  ?
>> And btw did you mean to use it like this, in the if  ?
>> 
>> `
>>  if (callerCL == null || VM.isSystemDomainLoader(callerCL)) {
>>             callerCL = Thread.currentThread().getContextClassLoader();
>> }
>> `
>
>> Hi Alan, regarding usage of class VM I get 'package jdk.internal.misc is declared in module java.base, which does not export it to module java.sql' Is there any concern to export it as well to module java.sql ? And btw did you mean to use it like this, in the if ?
>> 
>> `if (callerCL == null || VM.isSystemDomainLoader(callerCL)) { callerCL = Thread.currentThread().getContextClassLoader(); }`
> 
> It was just a passing comment, I didn't meant to suggest changing it as part of this PR. We have always think twice before adding qualified exports from java.base and this is case where java.sql is very "non-core", we don't want to give it any access to java.base internals.

Hi Alan, thanks for clarifying.  So I should only adjust the comment, correct ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1245204791

From kbarrett at openjdk.org  Wed Jun 28 15:23:17 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 28 Jun 2023 15:23:17 GMT
Subject: RFR: 8310948: Fix ignored-qualifiers warning in Hotspot
In-Reply-To: <hNI7tUjnrrsVnOlgJUzzLywNXljokcIjUBuH3DgtHdE=.f26e72bb-591f-48f1-8dfe-f4c85254b72f@github.com>
References: <hNI7tUjnrrsVnOlgJUzzLywNXljokcIjUBuH3DgtHdE=.f26e72bb-591f-48f1-8dfe-f4c85254b72f@github.com>
Message-ID: <X4FzsOemObQRxNjHib8U1eF8bdf31KdqEXus-I4zN8U=.38bd230c-6566-435b-9786-e3f7874fd44e@github.com>

On Tue, 27 Jun 2023 12:22:43 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this attempt to fix ignored-qualifiers warning.
> 
> Example warnings:
> 
> src/hotspot/share/oops/method.hpp:413:19: warning: 'volatile' type qualifier on return type has no effect [-Wignored-qualifiers]
>    CompiledMethod* volatile code() const;
>                    ^~~~~~~~~
> 
> 
> src/hotspot/share/jfr/periodic/jfrModuleEvent.cpp:65:20: warning: type qualifiers ignored on cast result type [-Wignored-qualifiers]
>     65 |   event.set_source((const ModuleEntry* const)from_module);
>        |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> 
> The proposed fix removes the ignored qualifiers.
> In a few AD files I replaced `const` with `constexpr` where I noticed that the method is returning a compile-time constant, and other platforms use `constexpr` on the same method.
> 
> Release, debug and slowdebug builds on Aarch64 / x64 and Mac / Linux complete without errors. Cross-compile GHA builds also pass.

Looks good.  Though mind-numbingly large; breaking something like this up into easier
to digest chunks can make reviewing easier.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14674#pullrequestreview-1503384263

From iklam at openjdk.org  Wed Jun 28 16:19:09 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 28 Jun 2023 16:19:09 GMT
Subject: RFR: 8310906: Fix -Wconversion warnings in runtime,
 oops and some code header files. [v4]
In-Reply-To: <2_AcdyIbMgXJp3ZmG7_O62U8Qhj1DDxUI41rWlpRkPI=.8863835b-faf8-4f3d-a933-d59b0c6e6f95@github.com>
References: <hvRAKRMNH1sBjeP5Ikhc5zt-4uyasNOEQ9Z0AeQbyAA=.64bdd842-d4b6-420d-a4e2-409567eb66b1@github.com>
 <2_AcdyIbMgXJp3ZmG7_O62U8Qhj1DDxUI41rWlpRkPI=.8863835b-faf8-4f3d-a933-d59b0c6e6f95@github.com>
Message-ID: <RZhYhNf-EJYiFiCYCPWjttbH4xRpv1-1Hk_74CWuse0=.b27b4a7e-1f80-49ca-ad4a-cb533dc29a0e@github.com>

On Wed, 28 Jun 2023 13:17:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is another version of PR https://github.com/openjdk/jdk/pull/14659 but I've added a pointer delta function in globalDefinitions.hpp to use for these pointer diff calculations that return int everywhere.  If the name is agreeable, I'll fix the other cases of this like this.  It's better than raw casts.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use pointer_delta_as_int for the name that uses pointer_delta, fix negative case to just do checked_cast.

LGTM.

src/hotspot/share/utilities/globalDefinitions.hpp line 529:

> 527: template <typename T>
> 528: inline int pointer_delta_as_int(const volatile T* left, const volatile T* right) {
> 529:   return checked_cast<int>(pointer_delta(left, right, sizeof(T)));

For clarity, I think you should add a comment saying the returned value is always non-negative.

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14675#pullrequestreview-1503498625
PR Review Comment: https://git.openjdk.org/jdk/pull/14675#discussion_r1245463745

From lkorinth at openjdk.org  Wed Jun 28 17:04:24 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 28 Jun 2023 17:04:24 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
Message-ID: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>

Remove trailing "blank" lines in source files.

I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.

The fix removes trailing lines matching ^[[:space:]]*$ in

- *.java
- *.cpp
- *.hpp
- *.c
- *.h 

I have applied the following bash script to each file:

    file="$1"
    
    while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
        truncate -s -1 "$file"
    done

`git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
`git diff --ignore-blank-lines  master` displays one change

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

Commit messages:
 - h
 - c
 - hpp
 - cpp
 - 8311043: Remove trailing blank lines in source files

Changes: https://git.openjdk.org/jdk/pull/14698/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14698&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311043
  Stats: 4529 lines in 4382 files changed: 0 ins; 4529 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14698.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14698/head:pull/14698

PR: https://git.openjdk.org/jdk/pull/14698

From fparain at openjdk.org  Wed Jun 28 17:30:54 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 28 Jun 2023 17:30:54 GMT
Subject: RFR: 8310906: Fix -Wconversion warnings in runtime,
 oops and some code header files. [v4]
In-Reply-To: <2_AcdyIbMgXJp3ZmG7_O62U8Qhj1DDxUI41rWlpRkPI=.8863835b-faf8-4f3d-a933-d59b0c6e6f95@github.com>
References: <hvRAKRMNH1sBjeP5Ikhc5zt-4uyasNOEQ9Z0AeQbyAA=.64bdd842-d4b6-420d-a4e2-409567eb66b1@github.com>
 <2_AcdyIbMgXJp3ZmG7_O62U8Qhj1DDxUI41rWlpRkPI=.8863835b-faf8-4f3d-a933-d59b0c6e6f95@github.com>
Message-ID: <bk2skwRyfbSpYplSewq8O0dtIxDFSTSEcpLZqA5pa1E=.a0a5907e-6574-4dc7-ada7-2ef0e132c3bb@github.com>

On Wed, 28 Jun 2023 13:17:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is another version of PR https://github.com/openjdk/jdk/pull/14659 but I've added a pointer delta function in globalDefinitions.hpp to use for these pointer diff calculations that return int everywhere.  If the name is agreeable, I'll fix the other cases of this like this.  It's better than raw casts.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use pointer_delta_as_int for the name that uses pointer_delta, fix negative case to just do checked_cast.

Looks good to me.

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

Marked as reviewed by fparain (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14675#pullrequestreview-1503631614

From never at openjdk.org  Wed Jun 28 18:31:57 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Wed, 28 Jun 2023 18:31:57 GMT
Subject: RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit [v4]
In-Reply-To: <bR9LN8hNjz3yHo9L_bh-0Q0j778pDnRKV9pmclEiYko=.5cb5fae1-131e-4845-bdb8-cbd55f5655c0@github.com>
References: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
 <bR9LN8hNjz3yHo9L_bh-0Q0j778pDnRKV9pmclEiYko=.5cb5fae1-131e-4845-bdb8-cbd55f5655c0@github.com>
Message-ID: <ByS77hVGP_wRuaDsG476V6iLaP5H7FP4sxEPz7EtXuc=.0a5efb85-a555-4424-9e48-51a271265f13@github.com>

On Tue, 27 Jun 2023 21:29:53 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> The VMSupport class is required for translating an exception between the HotSpot and libgraal heaps.
>> Loading it lazily can result in a loading exception, obscuring the exception being translated.
>> To avoid this, VMSupport is loaded eagerly along with the other vmClasses.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert to lazy loading of VMSupport

Right, I was forgetting about the virtual nature of this code.  Why can't the pending exception handling be in the respective virtual?  The partition between virtual and shared is kind of ugly.

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

PR Comment: https://git.openjdk.org/jdk/pull/14641#issuecomment-1611888908

From djelinski at openjdk.org  Wed Jun 28 18:44:52 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 28 Jun 2023 18:44:52 GMT
Subject: RFR: 8310948: Fix ignored-qualifiers warning in Hotspot
In-Reply-To: <hNI7tUjnrrsVnOlgJUzzLywNXljokcIjUBuH3DgtHdE=.f26e72bb-591f-48f1-8dfe-f4c85254b72f@github.com>
References: <hNI7tUjnrrsVnOlgJUzzLywNXljokcIjUBuH3DgtHdE=.f26e72bb-591f-48f1-8dfe-f4c85254b72f@github.com>
Message-ID: <ey4JW4DuOefSP0ZYwU8xTtD9Z5uFhZnAlKVldzyxxD8=.8ba4eec9-312e-4c0b-ace4-1641b9c3e891@github.com>

On Tue, 27 Jun 2023 12:22:43 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this attempt to fix ignored-qualifiers warning.
> 
> Example warnings:
> 
> src/hotspot/share/oops/method.hpp:413:19: warning: 'volatile' type qualifier on return type has no effect [-Wignored-qualifiers]
>    CompiledMethod* volatile code() const;
>                    ^~~~~~~~~
> 
> 
> src/hotspot/share/jfr/periodic/jfrModuleEvent.cpp:65:20: warning: type qualifiers ignored on cast result type [-Wignored-qualifiers]
>     65 |   event.set_source((const ModuleEntry* const)from_module);
>        |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> 
> The proposed fix removes the ignored qualifiers.
> In a few AD files I replaced `const` with `constexpr` where I noticed that the method is returning a compile-time constant, and other platforms use `constexpr` on the same method.
> 
> Release, debug and slowdebug builds on Aarch64 / x64 and Mac / Linux complete without errors. Cross-compile GHA builds also pass.

David: I think this part of the spec is relevant here:
> A non-class non-array prvalue cannot be [cv-qualified](https://en.cppreference.com/w/cpp/language/cv), [...]. (Note: a function call or cast expression may result in a prvalue of non-class cv-qualified type, but the cv-qualifier is generally immediately stripped out.)

[source](https://en.cppreference.com/w/cpp/language/value_category)
given that the cv qualifiers are immediately stripped by the compiler, there's no point in providing them.

In the particular volatile pointer case: the function performs a volatile read to get the pointer value (address). That address can then be used in a non-volatile manner.

Kim: I realize that it's a big change, so thank you very much for reviewing it anyway! I was prepared to split it up, just wanted to know if this warning is something we want to fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/14674#issuecomment-1611905364

From coleenp at openjdk.org  Wed Jun 28 19:48:30 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 28 Jun 2023 19:48:30 GMT
Subject: RFR: 8310906: Fix -Wconversion warnings in runtime,
 oops and some code header files. [v4]
In-Reply-To: <2_AcdyIbMgXJp3ZmG7_O62U8Qhj1DDxUI41rWlpRkPI=.8863835b-faf8-4f3d-a933-d59b0c6e6f95@github.com>
References: <hvRAKRMNH1sBjeP5Ikhc5zt-4uyasNOEQ9Z0AeQbyAA=.64bdd842-d4b6-420d-a4e2-409567eb66b1@github.com>
 <2_AcdyIbMgXJp3ZmG7_O62U8Qhj1DDxUI41rWlpRkPI=.8863835b-faf8-4f3d-a933-d59b0c6e6f95@github.com>
Message-ID: <g32A8WRE_VfgzNCLilh5YrWdvbwjchY8PQssRZ_RWFg=.6528aad6-4e43-46d1-865d-586ab2069eef@github.com>

On Wed, 28 Jun 2023 13:17:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is another version of PR https://github.com/openjdk/jdk/pull/14659 but I've added a pointer delta function in globalDefinitions.hpp to use for these pointer diff calculations that return int everywhere.  If the name is agreeable, I'll fix the other cases of this like this.  It's better than raw casts.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use pointer_delta_as_int for the name that uses pointer_delta, fix negative case to just do checked_cast.

Thanks Ioi and Fred and Stefan for suggestions.

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

PR Comment: https://git.openjdk.org/jdk/pull/14675#issuecomment-1612003549

From coleenp at openjdk.org  Wed Jun 28 19:48:29 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 28 Jun 2023 19:48:29 GMT
Subject: RFR: 8310906: Fix -Wconversion warnings in runtime,
 oops and some code header files. [v5]
In-Reply-To: <hvRAKRMNH1sBjeP5Ikhc5zt-4uyasNOEQ9Z0AeQbyAA=.64bdd842-d4b6-420d-a4e2-409567eb66b1@github.com>
References: <hvRAKRMNH1sBjeP5Ikhc5zt-4uyasNOEQ9Z0AeQbyAA=.64bdd842-d4b6-420d-a4e2-409567eb66b1@github.com>
Message-ID: <2DOW8GVmsByaJPfjmZEHunVO4-M5doNKK14_QOnjn-c=.101185e4-ff4e-4257-ab8d-5a0f3a945f82@github.com>

> This is another version of PR https://github.com/openjdk/jdk/pull/14659 but I've added a pointer delta function in globalDefinitions.hpp to use for these pointer diff calculations that return int everywhere.  If the name is agreeable, I'll fix the other cases of this like this.  It's better than raw casts.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Clarify that pointer_delta_as_int() returns a non-negative int.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14675/files
  - new: https://git.openjdk.org/jdk/pull/14675/files/9fed8c89..856cafd4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14675&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14675&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14675.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14675/head:pull/14675

PR: https://git.openjdk.org/jdk/pull/14675

From coleenp at openjdk.org  Wed Jun 28 19:48:30 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 28 Jun 2023 19:48:30 GMT
Subject: RFR: 8310906: Fix -Wconversion warnings in runtime,
 oops and some code header files. [v4]
In-Reply-To: <RZhYhNf-EJYiFiCYCPWjttbH4xRpv1-1Hk_74CWuse0=.b27b4a7e-1f80-49ca-ad4a-cb533dc29a0e@github.com>
References: <hvRAKRMNH1sBjeP5Ikhc5zt-4uyasNOEQ9Z0AeQbyAA=.64bdd842-d4b6-420d-a4e2-409567eb66b1@github.com>
 <2_AcdyIbMgXJp3ZmG7_O62U8Qhj1DDxUI41rWlpRkPI=.8863835b-faf8-4f3d-a933-d59b0c6e6f95@github.com>
 <RZhYhNf-EJYiFiCYCPWjttbH4xRpv1-1Hk_74CWuse0=.b27b4a7e-1f80-49ca-ad4a-cb533dc29a0e@github.com>
Message-ID: <dWSDDlxc7G48eu3CBl4OMQod2CXOfc87eU6pZ1276Yg=.259f7720-6a3f-491c-8b45-fe55f505d8e7@github.com>

On Wed, 28 Jun 2023 16:15:39 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use pointer_delta_as_int for the name that uses pointer_delta, fix negative case to just do checked_cast.
>
> src/hotspot/share/utilities/globalDefinitions.hpp line 529:
> 
>> 527: template <typename T>
>> 528: inline int pointer_delta_as_int(const volatile T* left, const volatile T* right) {
>> 529:   return checked_cast<int>(pointer_delta(left, right, sizeof(T)));
> 
> For clarity, I think you should add a comment saying the returned value is always non-negative.

done, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14675#discussion_r1245681394

From coleenp at openjdk.org  Wed Jun 28 19:48:30 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 28 Jun 2023 19:48:30 GMT
Subject: Integrated: 8310906: Fix -Wconversion warnings in runtime,
 oops and some code header files.
In-Reply-To: <hvRAKRMNH1sBjeP5Ikhc5zt-4uyasNOEQ9Z0AeQbyAA=.64bdd842-d4b6-420d-a4e2-409567eb66b1@github.com>
References: <hvRAKRMNH1sBjeP5Ikhc5zt-4uyasNOEQ9Z0AeQbyAA=.64bdd842-d4b6-420d-a4e2-409567eb66b1@github.com>
Message-ID: <hWrS78FSU-kMLL6ixL-UOrBMUZTzICKmzkQJZ-ECtXc=.c908d2cc-edbb-4376-8070-00293f34936a@github.com>

On Tue, 27 Jun 2023 12:41:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is another version of PR https://github.com/openjdk/jdk/pull/14659 but I've added a pointer delta function in globalDefinitions.hpp to use for these pointer diff calculations that return int everywhere.  If the name is agreeable, I'll fix the other cases of this like this.  It's better than raw casts.
> Tested with tier1-4.

This pull request has now been integrated.

Changeset: 9f46fc28
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9f46fc28426630399ca39d443403cc3a7be58854
Stats:     60 lines in 32 files changed: 8 ins; 0 del; 52 mod

8310906: Fix -Wconversion warnings in runtime, oops and some code header files.

Reviewed-by: iklam, fparain

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

PR: https://git.openjdk.org/jdk/pull/14675

From dlong at openjdk.org  Wed Jun 28 20:55:54 2023
From: dlong at openjdk.org (Dean Long)
Date: Wed, 28 Jun 2023 20:55:54 GMT
Subject: RFR: 8310948: Fix ignored-qualifiers warning in Hotspot
In-Reply-To: <hNI7tUjnrrsVnOlgJUzzLywNXljokcIjUBuH3DgtHdE=.f26e72bb-591f-48f1-8dfe-f4c85254b72f@github.com>
References: <hNI7tUjnrrsVnOlgJUzzLywNXljokcIjUBuH3DgtHdE=.f26e72bb-591f-48f1-8dfe-f4c85254b72f@github.com>
Message-ID: <WmSFDcDRYWrdqVP2pHLL8S5Z7UNYbxORUxHnFlhVrxQ=.78a3839d-3a92-4364-a413-4519405f3591@github.com>

On Tue, 27 Jun 2023 12:22:43 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this attempt to fix ignored-qualifiers warning.
> 
> Example warnings:
> 
> src/hotspot/share/oops/method.hpp:413:19: warning: 'volatile' type qualifier on return type has no effect [-Wignored-qualifiers]
>    CompiledMethod* volatile code() const;
>                    ^~~~~~~~~
> 
> 
> src/hotspot/share/jfr/periodic/jfrModuleEvent.cpp:65:20: warning: type qualifiers ignored on cast result type [-Wignored-qualifiers]
>     65 |   event.set_source((const ModuleEntry* const)from_module);
>        |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> 
> The proposed fix removes the ignored qualifiers.
> In a few AD files I replaced `const` with `constexpr` where I noticed that the method is returning a compile-time constant, and other platforms use `constexpr` on the same method.
> 
> Release, debug and slowdebug builds on Aarch64 / x64 and Mac / Linux complete without errors. Cross-compile GHA builds also pass.

In the example, was the intention perhaps `volatile CompiledMethod*` instead of `CompiledMethod* volatile`?

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

PR Comment: https://git.openjdk.org/jdk/pull/14674#issuecomment-1612090389

From dnsimon at openjdk.org  Wed Jun 28 21:21:11 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 28 Jun 2023 21:21:11 GMT
Subject: RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit [v5]
In-Reply-To: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
References: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
Message-ID: <Am7TNzGn_KTfxFEIV_ytEFYckL7Bvp_oqRYAGA5eT38=.794dff2b-7508-496e-9857-e03175c77ebf@github.com>

> The VMSupport class is required for translating an exception between the HotSpot and libgraal heaps.
> Loading it lazily can result in a loading exception, obscuring the exception being translated.
> To avoid this, VMSupport is loaded eagerly along with the other vmClasses.

Doug Simon has updated the pull request incrementally with one additional commit since the last revision:

  [skip ci] handle pending HotSpot exception closer to site causing exception

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14641/files
  - new: https://git.openjdk.org/jdk/pull/14641/files/734903a8..9236128a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14641&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14641&range=03-04

  Stats: 145 lines in 3 files changed: 102 ins; 25 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/14641.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14641/head:pull/14641

PR: https://git.openjdk.org/jdk/pull/14641

From dnsimon at openjdk.org  Wed Jun 28 21:21:13 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 28 Jun 2023 21:21:13 GMT
Subject: RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit [v4]
In-Reply-To: <ByS77hVGP_wRuaDsG476V6iLaP5H7FP4sxEPz7EtXuc=.0a5efb85-a555-4424-9e48-51a271265f13@github.com>
References: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
 <bR9LN8hNjz3yHo9L_bh-0Q0j778pDnRKV9pmclEiYko=.5cb5fae1-131e-4845-bdb8-cbd55f5655c0@github.com>
 <ByS77hVGP_wRuaDsG476V6iLaP5H7FP4sxEPz7EtXuc=.0a5efb85-a555-4424-9e48-51a271265f13@github.com>
Message-ID: <h6nI5F9HeHnJtbpN8AES7_jHk2P9MrOcsb_jSN7Il8k=.163c5910-5947-4727-934e-a2c5761a407d@github.com>

On Wed, 28 Jun 2023 18:28:37 GMT, Tom Rodriguez <never at openjdk.org> wrote:

> Why can't the pending exception handling be in the respective virtual?

Done: 9236128ad1b7297c8c4e9d3022b88c3ab3278022

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

PR Comment: https://git.openjdk.org/jdk/pull/14641#issuecomment-1612113760

From never at openjdk.org  Wed Jun 28 23:59:55 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Wed, 28 Jun 2023 23:59:55 GMT
Subject: RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit [v5]
In-Reply-To: <Am7TNzGn_KTfxFEIV_ytEFYckL7Bvp_oqRYAGA5eT38=.794dff2b-7508-496e-9857-e03175c77ebf@github.com>
References: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
 <Am7TNzGn_KTfxFEIV_ytEFYckL7Bvp_oqRYAGA5eT38=.794dff2b-7508-496e-9857-e03175c77ebf@github.com>
Message-ID: <eLDku215x7cPr18LEOmCV7i8jSlwooqFQHvpdRY1jr0=.9e8e3d27-1a9b-40c1-9033-105f55ba37fd@github.com>

On Wed, 28 Jun 2023 21:21:11 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> The VMSupport class is required for translating an exception between the HotSpot and libgraal heaps.
>> Loading it lazily can result in a loading exception, obscuring the exception being translated.
>> To avoid this, VMSupport is loaded eagerly along with the other vmClasses.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   [skip ci] handle pending HotSpot exception closer to site causing exception

That's more clear to me.  Thanks!

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

Marked as reviewed by never (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14641#pullrequestreview-1504385398

From dholmes at openjdk.org  Thu Jun 29 02:15:55 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 29 Jun 2023 02:15:55 GMT
Subject: RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit [v5]
In-Reply-To: <Am7TNzGn_KTfxFEIV_ytEFYckL7Bvp_oqRYAGA5eT38=.794dff2b-7508-496e-9857-e03175c77ebf@github.com>
References: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
 <Am7TNzGn_KTfxFEIV_ytEFYckL7Bvp_oqRYAGA5eT38=.794dff2b-7508-496e-9857-e03175c77ebf@github.com>
Message-ID: <2UadNxsZ2qr29Z5jPOyIQTNgjvTGY_7hRpr8W8UDYBE=.4b83127f-5258-4ef1-93dd-7460aa514adc@github.com>

On Wed, 28 Jun 2023 21:21:11 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> The VMSupport class is required for translating an exception between the HotSpot and libgraal heaps.
>> Loading it lazily can result in a loading exception, obscuring the exception being translated.
>> To avoid this, VMSupport is loaded eagerly along with the other vmClasses.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   [skip ci] handle pending HotSpot exception closer to site causing exception

This is now isolated to JVMCI code that I'm not familiar with, so don't feel competent to review. The general idea seems okay but I'm not familiar enough with the details. Someone from the compiler team should review this now.

Thanks.

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

PR Review: https://git.openjdk.org/jdk/pull/14641#pullrequestreview-1504459576

From amenkov at openjdk.org  Thu Jun 29 04:41:20 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 29 Jun 2023 04:41:20 GMT
Subject: RFR: JDK-8310066: Improve test coverage for JVMTI GetThreadState
 on carrier and mounted vthread [v3]
In-Reply-To: <_8UnxXrT842BKmJ98GlmJyL21yzM0dhGOkeeK0Mnf2g=.c90b2826-922c-4838-b816-8bf3b5933d87@github.com>
References: <_8UnxXrT842BKmJ98GlmJyL21yzM0dhGOkeeK0Mnf2g=.c90b2826-922c-4838-b816-8bf3b5933d87@github.com>
Message-ID: <VInLWm0-r-6j7reX915h7M5XdRsml4r-XWvyoLxYN54=.f58a427f-95a8-4190-b7ff-804a564197ef@github.com>

> This is follow-up JDK-8307153/JDK-8309612 (JVMTI GetThreadState on carrier should return STATE_WAITING)
> New test tests GetThreadState for different thread states.
> The test detected a bug in the implementation, new issue is created: JDK-8310584
> Corresponding testcases are commented now in the test, fix for JDK-8310584 will uncomment them

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  spurious wakeups

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14622/files
  - new: https://git.openjdk.org/jdk/pull/14622/files/b5b39bcd..6c517cef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14622&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14622&range=01-02

  Stats: 124 lines in 2 files changed: 88 ins; 0 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/14622.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14622/head:pull/14622

PR: https://git.openjdk.org/jdk/pull/14622

From amenkov at openjdk.org  Thu Jun 29 04:51:34 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 29 Jun 2023 04:51:34 GMT
Subject: RFR: JDK-8310066: Improve test coverage for JVMTI GetThreadState
 on carrier and mounted vthread [v2]
In-Reply-To: <q9qTVfusiKqVeyY-kv9K7TdzJGEhcv8I9pmjTNjHqC4=.8ada8f11-d647-4189-ace4-7788c0a4eae4@github.com>
References: <_8UnxXrT842BKmJ98GlmJyL21yzM0dhGOkeeK0Mnf2g=.c90b2826-922c-4838-b816-8bf3b5933d87@github.com>
 <WeG8y6Wt96LudgWu0cLSDXiMl8WYFdvihb8hiVDNbK8=.7a75ef50-73ea-4380-a58a-7c3f1b8ec52a@github.com>
 <q9qTVfusiKqVeyY-kv9K7TdzJGEhcv8I9pmjTNjHqC4=.8ada8f11-d647-4189-ace4-7788c0a4eae4@github.com>
Message-ID: <32jqqEQg1F9FdmlxiB19zznO0VlM1olEgwiOF7KUjos=.8bfb57e6-b83a-42b0-a20b-f091590aadf0@github.com>

On Wed, 28 Jun 2023 07:37:00 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The test is great. I realize it is not easy to make it fully reliable though. So, will need another pass.

Good point about spurious wakeups.
Updated the test to handle them.
Now for WAITING scenarios the test suspends test thread and ensures it's waiting. While the thread is suspended (either carrier or virtual) we can safely verify thread states

> test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadStateMountedTest/GetThreadStateMountedTest.java line 117:
> 
>> 115:                 } catch (InterruptedException ex) {
>> 116:                     // expected, ignore
>> 117:                 }
> 
> Shout this code account for spurious wakeups?

Fixed

> test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadStateMountedTest/GetThreadStateMountedTest.java line 241:
> 
>> 239:     private static native void waitInNative();
>> 240:     // Signals waitInNative() to exit.
>> 241:     private static native void endWait();
> 
> Q: Where is this native method invoked?

Good catch. Test thread inNative testcase never exits, it's terminated on the test exit.
Fixed.

> test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadStateMountedTest/libGetThreadStateMountedTest.cpp line 73:
> 
>> 71:     jint unexpected = state - actual_full;
>> 72:     LOG("  ERROR: some unexpected bits are set (%x): %s\n",
>> 73:        unexpected, TranslateState(unexpected));
> 
> Nit: lines 65, 73 have wrong indent.

Fixed.

> test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadStateMountedTest/libGetThreadStateMountedTest.cpp line 176:
> 
>> 174:   while (!time_to_exit) {
>> 175:     sleep_ms(100);
>> 176:   }
> 
> Is this loop reliable in terms of thread states?

The code is pure native (sleep_ms uses native functions, it does not interact with JVM), so there is no thread state changes

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

PR Comment: https://git.openjdk.org/jdk/pull/14622#issuecomment-1612423518
PR Review Comment: https://git.openjdk.org/jdk/pull/14622#discussion_r1246097094
PR Review Comment: https://git.openjdk.org/jdk/pull/14622#discussion_r1246096797
PR Review Comment: https://git.openjdk.org/jdk/pull/14622#discussion_r1246098484
PR Review Comment: https://git.openjdk.org/jdk/pull/14622#discussion_r1246098388

From djelinski at openjdk.org  Thu Jun 29 05:04:54 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 29 Jun 2023 05:04:54 GMT
Subject: RFR: 8310948: Fix ignored-qualifiers warning in Hotspot
In-Reply-To: <hNI7tUjnrrsVnOlgJUzzLywNXljokcIjUBuH3DgtHdE=.f26e72bb-591f-48f1-8dfe-f4c85254b72f@github.com>
References: <hNI7tUjnrrsVnOlgJUzzLywNXljokcIjUBuH3DgtHdE=.f26e72bb-591f-48f1-8dfe-f4c85254b72f@github.com>
Message-ID: <kB6MsrQ9RbljJF4Bpf_DVpmN8yGeYpa17iT09rcC8u4=.aa49c627-f710-4e38-9e46-c982922a05ec@github.com>

On Tue, 27 Jun 2023 12:22:43 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this attempt to fix ignored-qualifiers warning.
> 
> Example warnings:
> 
> src/hotspot/share/oops/method.hpp:413:19: warning: 'volatile' type qualifier on return type has no effect [-Wignored-qualifiers]
>    CompiledMethod* volatile code() const;
>                    ^~~~~~~~~
> 
> 
> src/hotspot/share/jfr/periodic/jfrModuleEvent.cpp:65:20: warning: type qualifiers ignored on cast result type [-Wignored-qualifiers]
>     65 |   event.set_source((const ModuleEntry* const)from_module);
>        |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> 
> The proposed fix removes the ignored qualifiers.
> In a few AD files I replaced `const` with `constexpr` where I noticed that the method is returning a compile-time constant, and other platforms use `constexpr` on the same method.
> 
> Release, debug and slowdebug builds on Aarch64 / x64 and Mac / Linux complete without errors. Cross-compile GHA builds also pass.

I don't think that was the intention. There's a comment on `Method::_code` stating that the pointer can change at any point (so the pointer was supposed to be volatile), and `class CompiledMethod` does not have any `volatile` - qualified methods.

There are similar cases where `const` pointer to a class was returned involving `JavaThread`, `ReferenceProcessor`, `PSCardTable` and `ShenandoahHeapRegion`; I suppose we could review if `const` could be added to the returned class, but that's outside of the scope of this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/14674#issuecomment-1612435102

From erikj at openjdk.org  Thu Jun 29 07:23:54 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 29 Jun 2023 07:23:54 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <nuJPc-yjOE7DrniF-EEjhLk-HQOBXJs4Ju4rWV4xxpw=.29e0f50a-084f-4091-8d96-ef05ab41427b@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14698#pullrequestreview-1504702261

From dholmes at openjdk.org  Thu Jun 29 07:43:58 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 29 Jun 2023 07:43:58 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <EQuIZ3iWFCSLc17HhVUhumjSNcu31poFHTgiKUDI6fY=.d11b918f-1318-4e34-b2fa-e458ef576f55@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

This seems to run contrary to the requirement that files end in a newline, which git will complain about if the newline is missing.

It also seems far too large and disruptive.

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1612567676

From erikj at openjdk.org  Thu Jun 29 08:00:58 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 29 Jun 2023 08:00:58 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <EQuIZ3iWFCSLc17HhVUhumjSNcu31poFHTgiKUDI6fY=.d11b918f-1318-4e34-b2fa-e458ef576f55@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
 <EQuIZ3iWFCSLc17HhVUhumjSNcu31poFHTgiKUDI6fY=.d11b918f-1318-4e34-b2fa-e458ef576f55@github.com>
Message-ID: <Jo4ev4ByTzxMNpDvKGyYL9G8TzbpVerc1YXde4iu_5Q=.afe5e6d2-63a5-4956-9d5c-17675789a051@github.com>

On Thu, 29 Jun 2023 07:41:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This seems to run contrary to the requirement that files end in a newline, which git will complain about if the newline is missing.

The patch is leaving exactly one newline at the end of the file.

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1612588091

From lkorinth at openjdk.org  Thu Jun 29 08:58:59 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 29 Jun 2023 08:58:59 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <EQuIZ3iWFCSLc17HhVUhumjSNcu31poFHTgiKUDI6fY=.d11b918f-1318-4e34-b2fa-e458ef576f55@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
 <EQuIZ3iWFCSLc17HhVUhumjSNcu31poFHTgiKUDI6fY=.d11b918f-1318-4e34-b2fa-e458ef576f55@github.com>
Message-ID: <z1LaNlMKfruphxc495xDHe2Ou64psUrXMobtiqqnqqk=.cdf515c9-2243-42ba-bea6-d24967ce3634@github.com>

On Thu, 29 Jun 2023 07:41:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This seems to run contrary to the requirement that files end in a newline, which git will complain about if the newline is missing.
>
> It also seems far too large and disruptive.

Do you still think it is too disruptive after Erik's explanation?  I could split it in more reviews, but I thought that maybe it would just make the review harder. I was hoping the two `git diff` commands I gave in my first comment in combination with the clean script would make the change seem reviewable.

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1612660457

From asemenov at openjdk.org  Thu Jun 29 09:11:05 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Thu, 29 Jun 2023 09:11:05 GMT
Subject: Integrated: 8308286 Fix clang warnings in linux code
In-Reply-To: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
Message-ID: <RJfR256QMKuXBAiw1oWhHWImDH-oLic1q__QwUdR6OU=.fa227014-c5f4-4466-9677-a6061cf39c4a@github.com>

On Wed, 17 May 2023 12:28:47 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
> They can be fixed with small changes.

This pull request has now been integrated.

Changeset: 98a954ee
Author:    Artem Semenov <asemenov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/98a954eebc4f97dd16cb89bd4f1122952c8482ca
Stats:     20 lines in 6 files changed: 14 ins; 0 del; 6 mod

8308286: Fix clang warnings in linux code

Reviewed-by: avu, djelinski

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

PR: https://git.openjdk.org/jdk/pull/14033

From kevinw at openjdk.org  Thu Jun 29 11:55:55 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 29 Jun 2023 11:55:55 GMT
Subject: RFR: 8311000: missing @since info in jdk.management
Message-ID: <-f8oRj4ThTKK-rAY9GnVSGlXrPLuIVcuz40dJBaFsF8=.fd87ccc0-858a-4e14-b2a4-d666faf1aa98@github.com>

Simple addition of a doc tag.  

src/share/classes/com/sun/management/GarbageCollectionNotificationInfo.java is introduced in jdk7 by
7036199: Adding a notification to the implementation of GarbageCollectorMXBeans

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

Commit messages:
 - 8311000: missing @since info in jdk.management

Changes: https://git.openjdk.org/jdk/pull/14708/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14708&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311000
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14708.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14708/head:pull/14708

PR: https://git.openjdk.org/jdk/pull/14708

From coleenp at openjdk.org  Thu Jun 29 12:03:56 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 29 Jun 2023 12:03:56 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <lC5MtlMFgekl4P8wRlF6OercN58zegLgPAXn6-s82E4=.8121c9cd-7f0f-43c0-8cc6-963b3a8b8cbc@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

Why do we care about this?

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613018234

From dholmes at openjdk.org  Thu Jun 29 12:14:55 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 29 Jun 2023 12:14:55 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <3rq9p7Pqn9UcVlQ5E0XMltGBBgmpWeLiz0k7HDi53qE=.fa670ef1-cd6c-4e4a-9ec3-89d5a2fec0ef@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

Neither the PR diffs nor the webrev make it easy to see exactly what is being changed here. It appeared to me that the last empty line of each file was being deleted, leaving no newline at the end.

But to me this is too disruptive with no tangible benefit. And you need buy-in from all the different areas affected by this.

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613043398

From coleenp at openjdk.org  Thu Jun 29 12:25:16 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 29 Jun 2023 12:25:16 GMT
Subject: RFR: 8311077: Fix -Wconversion warnings in jvmti code.
Message-ID: <01jxrp1E-_5hGZ91QI0Og2XgbksXszXHWSzRiiuX9OM=.8d132e37-3821-4b48-a8e4-c3f2efb7b3ea@github.com>

Please review change for mostly fixing return types in the constant pool and metadata to fix -Wconversion warnings in JVMTI code.
Tested with tier1-4.

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

Commit messages:
 - Fix -Wconversion warnings in jvmti code.

Changes: https://git.openjdk.org/jdk/pull/14710/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14710&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311077
  Stats: 100 lines in 16 files changed: 4 ins; 2 del; 94 mod
  Patch: https://git.openjdk.org/jdk/pull/14710.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14710/head:pull/14710

PR: https://git.openjdk.org/jdk/pull/14710

From lkorinth at openjdk.org  Thu Jun 29 12:38:57 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 29 Jun 2023 12:38:57 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <lC5MtlMFgekl4P8wRlF6OercN58zegLgPAXn6-s82E4=.8121c9cd-7f0f-43c0-8cc6-963b3a8b8cbc@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
 <lC5MtlMFgekl4P8wRlF6OercN58zegLgPAXn6-s82E4=.8121c9cd-7f0f-43c0-8cc6-963b3a8b8cbc@github.com>
Message-ID: <vkPgWAbLJRXEPOQ0alkrWJ7Gv7jLDEF3ak1ipe9xxZw=.5b93f57d-7ddb-42fb-b41b-76f4e3193d78@github.com>

On Thu, 29 Jun 2023 12:01:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Why do we care about this?

I care because of global-whitespace-cleanup-mode (in emacs). It helps me remove trailing whitespaces and blanklines when saving but it will not fix a file that was "dirty" when it was opened. Trailing blank lines triggers it not to clean whitespaces for me.

And it does not look good.

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613095390

From coleenp at openjdk.org  Thu Jun 29 12:42:56 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 29 Jun 2023 12:42:56 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <D-8wt_ou32I2rNGxmmplmzp0RP50tw07-gVbQTY9vIc=.ffbe6128-5ed0-4597-a124-4edc21a59b98@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

You could fix your emacs functions.

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613106245

From lkorinth at openjdk.org  Thu Jun 29 13:08:59 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 29 Jun 2023 13:08:59 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <3rq9p7Pqn9UcVlQ5E0XMltGBBgmpWeLiz0k7HDi53qE=.fa670ef1-cd6c-4e4a-9ec3-89d5a2fec0ef@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
 <3rq9p7Pqn9UcVlQ5E0XMltGBBgmpWeLiz0k7HDi53qE=.fa670ef1-cd6c-4e4a-9ec3-89d5a2fec0ef@github.com>
Message-ID: <jLa8PV1GIQpbUHJVsxcmv8B6osgOh6Gl--cFTsxxQRE=.037e8a3c-080a-4dce-bf14-b63779c34fd3@github.com>

On Thu, 29 Jun 2023 12:11:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Neither the PR diffs nor the webrev make it easy to see exactly what is being changed here. It appeared to me that the last empty line of each file was being deleted, leaving no newline at the end.

My changes look like this in the diff output

 }
-

Removal of the last newline would look like this:

-}
+}
\ No newline at end of file

(both with `git diff` and `git diff --unified`) 

I have not tested if this is also true for the generated webrevs, but I think that is precisely how they are created.

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613152641

From duke at openjdk.org  Thu Jun 29 14:09:57 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Thu, 29 Jun 2023 14:09:57 GMT
Subject: RFR: 8309979: BootstrapMethods attribute is missing in class files
 recreated by SA [v2]
In-Reply-To: <XMnH_cFQgCnx13I_1SqV-Br6T1QDwlbz9FzQZ-HlEaE=.f93bc591-726f-45fe-95ac-d1d6cfe79d06@github.com>
References: <nSooA6CtKm8LsaxzYdqJ6mtVV0os-kT5F2xNvYI4lJo=.c27bd28e-88d3-4bcb-ac3d-9036140eeff0@github.com>
 <i3PjGx_wbQ63SlwcWL5eBr28sDUb1_dPQ8Q0P3Qgzds=.5f11a8e5-714c-45c0-87e6-e612bb50b28b@github.com>
 <XMnH_cFQgCnx13I_1SqV-Br6T1QDwlbz9FzQZ-HlEaE=.f93bc591-726f-45fe-95ac-d1d6cfe79d06@github.com>
Message-ID: <UrXKZRledFEjHKcFDefVcFZbLOw88GvF5eO4maEdwe0=.9fd79d49-06ce-4788-94ec-086de5b668dd@github.com>

On Fri, 16 Jun 2023 18:10:58 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments by plummercj
>>   
>>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> Yes, it is already problem listed. How did you run the tests? If you use "make test" it should be including the problem list automatically.

@plummercj @kevinjwalls can either of you sponsor it as well?

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

PR Comment: https://git.openjdk.org/jdk/pull/14495#issuecomment-1613247796

From lkorinth at openjdk.org  Thu Jun 29 14:12:55 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 29 Jun 2023 14:12:55 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <D-8wt_ou32I2rNGxmmplmzp0RP50tw07-gVbQTY9vIc=.ffbe6128-5ed0-4597-a124-4edc21a59b98@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
 <D-8wt_ou32I2rNGxmmplmzp0RP50tw07-gVbQTY9vIc=.ffbe6128-5ed0-4597-a124-4edc21a59b98@github.com>
Message-ID: <pfRQFPE48dsB4zX-Rf7hnkzlyMzdctcY-veiO1KeN70=.bffbbead-ef44-461c-8362-21418c7db00e@github.com>

On Thu, 29 Jun 2023 12:40:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> You could fix your emacs functions.

It is a *very nice* feature of global-whitespace-cleanup-mode

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613252347

From sspitsyn at openjdk.org  Thu Jun 29 14:13:59 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 29 Jun 2023 14:13:59 GMT
Subject: RFR: JDK-8310066: Improve test coverage for JVMTI GetThreadState
 on carrier and mounted vthread [v3]
In-Reply-To: <VInLWm0-r-6j7reX915h7M5XdRsml4r-XWvyoLxYN54=.f58a427f-95a8-4190-b7ff-804a564197ef@github.com>
References: <_8UnxXrT842BKmJ98GlmJyL21yzM0dhGOkeeK0Mnf2g=.c90b2826-922c-4838-b816-8bf3b5933d87@github.com>
 <VInLWm0-r-6j7reX915h7M5XdRsml4r-XWvyoLxYN54=.f58a427f-95a8-4190-b7ff-804a564197ef@github.com>
Message-ID: <tV7aHhjwSGiNDrnMHVcx6aea2BCUEZJg-7DmR5I4iy8=.de110fe0-6b99-4310-a2f8-1ecc37c6e856@github.com>

On Thu, 29 Jun 2023 04:41:20 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> This is follow-up JDK-8307153/JDK-8309612 (JVMTI GetThreadState on carrier should return STATE_WAITING)
>> New test tests GetThreadState for different thread states.
>> The test detected a bug in the implementation, new issue is created: JDK-8310584
>> Corresponding testcases are commented now in the test, fix for JDK-8310584 will uncomment them
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   spurious wakeups

test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadStateMountedTest/GetThreadStateMountedTest.java line 41:

> 39: /**
> 40:  * The test implements different scenarios to get desired JVMTI thread states.
> 41:  * For each scenarios test also checks states after carrier and virtual threads suspend/resume

Nit: `each scenarios` => `each scenario`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14622#discussion_r1246677973

From kevinw at openjdk.org  Thu Jun 29 14:20:08 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 29 Jun 2023 14:20:08 GMT
Subject: RFR: 8309979: BootstrapMethods attribute is missing in class files
 recreated by SA [v3]
In-Reply-To: <AP8yKMhhMNIqR5yvcLylrZcoiMh7riMYbxK4jpAwpCs=.79aa5a8f-670b-43d2-815c-245fe8d47868@github.com>
References: <nSooA6CtKm8LsaxzYdqJ6mtVV0os-kT5F2xNvYI4lJo=.c27bd28e-88d3-4bcb-ac3d-9036140eeff0@github.com>
 <AP8yKMhhMNIqR5yvcLylrZcoiMh7riMYbxK4jpAwpCs=.79aa5a8f-670b-43d2-815c-245fe8d47868@github.com>
Message-ID: <WiRPc_lSZr0Xa7dBRd-EjTnR4aoqpS0ipQTlrsPnCQQ=.d84a3e49-0e08-4825-a7b5-e100ac6c75b5@github.com>

On Thu, 22 Jun 2023 15:37:11 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> Please review this PR that extends SA to write BootstrapMethods attribute when dumping the class files.
>> 
>> Tested it by dumping the class file for java/lang/String and comparing the BootstrapMethods attribute shown by javap for the original and the dumped class.
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment about the layout of operands array in constant pool
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

Yes 8-)

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

PR Comment: https://git.openjdk.org/jdk/pull/14495#issuecomment-1613261723

From duke at openjdk.org  Thu Jun 29 14:20:09 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Thu, 29 Jun 2023 14:20:09 GMT
Subject: RFR: 8309979: BootstrapMethods attribute is missing in class files
 recreated by SA [v3]
In-Reply-To: <WiRPc_lSZr0Xa7dBRd-EjTnR4aoqpS0ipQTlrsPnCQQ=.d84a3e49-0e08-4825-a7b5-e100ac6c75b5@github.com>
References: <nSooA6CtKm8LsaxzYdqJ6mtVV0os-kT5F2xNvYI4lJo=.c27bd28e-88d3-4bcb-ac3d-9036140eeff0@github.com>
 <AP8yKMhhMNIqR5yvcLylrZcoiMh7riMYbxK4jpAwpCs=.79aa5a8f-670b-43d2-815c-245fe8d47868@github.com>
 <WiRPc_lSZr0Xa7dBRd-EjTnR4aoqpS0ipQTlrsPnCQQ=.d84a3e49-0e08-4825-a7b5-e100ac6c75b5@github.com>
Message-ID: <hqUoObaQqQi5cLa56weIuIlQNWIGVeLCaUxZaJxKUnk=.e346c36c-b36d-4cb9-bd27-4977cdf828d3@github.com>

On Thu, 29 Jun 2023 14:16:16 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add comment about the layout of operands array in constant pool
>>   
>>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> Yes 8-)

@kevinjwalls thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/14495#issuecomment-1613263248

From duke at openjdk.org  Thu Jun 29 14:20:11 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Thu, 29 Jun 2023 14:20:11 GMT
Subject: Integrated: 8309979: BootstrapMethods attribute is missing in class
 files recreated by SA
In-Reply-To: <nSooA6CtKm8LsaxzYdqJ6mtVV0os-kT5F2xNvYI4lJo=.c27bd28e-88d3-4bcb-ac3d-9036140eeff0@github.com>
References: <nSooA6CtKm8LsaxzYdqJ6mtVV0os-kT5F2xNvYI4lJo=.c27bd28e-88d3-4bcb-ac3d-9036140eeff0@github.com>
Message-ID: <lK1sfLbQ1QF5ba1g0NECIuHLMCSvsdl5Jiuxctaf8NI=.30c2730b-6454-4b20-b5b9-cedd603d235b@github.com>

On Thu, 15 Jun 2023 15:06:54 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

> Please review this PR that extends SA to write BootstrapMethods attribute when dumping the class files.
> 
> Tested it by dumping the class file for java/lang/String and comparing the BootstrapMethods attribute shown by javap for the original and the dumped class.

This pull request has now been integrated.

Changeset: 05c2b6cd
Author:    Ashutosh Mehra <asmehra at redhat.com>
Committer: Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/05c2b6cd47c68d96dcb7b3db594a334e05c6ee36
Stats:     92 lines in 3 files changed: 84 ins; 2 del; 6 mod

8309979: BootstrapMethods attribute is missing in class files recreated by SA

Reviewed-by: cjplummer, kevinw

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

PR: https://git.openjdk.org/jdk/pull/14495

From sspitsyn at openjdk.org  Thu Jun 29 14:28:57 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 29 Jun 2023 14:28:57 GMT
Subject: RFR: JDK-8310066: Improve test coverage for JVMTI GetThreadState
 on carrier and mounted vthread [v3]
In-Reply-To: <VInLWm0-r-6j7reX915h7M5XdRsml4r-XWvyoLxYN54=.f58a427f-95a8-4190-b7ff-804a564197ef@github.com>
References: <_8UnxXrT842BKmJ98GlmJyL21yzM0dhGOkeeK0Mnf2g=.c90b2826-922c-4838-b816-8bf3b5933d87@github.com>
 <VInLWm0-r-6j7reX915h7M5XdRsml4r-XWvyoLxYN54=.f58a427f-95a8-4190-b7ff-804a564197ef@github.com>
Message-ID: <AFhGb86TenuURRlW7F805T_qXAwCRu1C--8r40VW6uU=.bdbac40d-78ff-4cd1-a4fa-fe6f337e931b@github.com>

On Thu, 29 Jun 2023 04:41:20 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> This is follow-up JDK-8307153/JDK-8309612 (JVMTI GetThreadState on carrier should return STATE_WAITING)
>> New test tests GetThreadState for different thread states.
>> The test detected a bug in the implementation, new issue is created: JDK-8310584
>> Corresponding testcases are commented now in the test, fix for JDK-8310584 will uncomment them
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   spurious wakeups

test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadStateMountedTest/GetThreadStateMountedTest.java line 62:

> 60:         TestStatus status = new TestStatus("JVMTI_THREAD_STATE_RUNNABLE");
> 61:         CountDownLatch ready = new CountDownLatch(1);
> 62:         final boolean[] stopFlag = new boolean[1];

Q: It is not clear why an array is needed instead of non-final local. The same question for `waiting()` method below.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14622#discussion_r1246698740

From coleenp at openjdk.org  Thu Jun 29 15:46:57 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 29 Jun 2023 15:46:57 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <DR0fysIfEikX8EG5J7RlPyej6GFMsw-_WkeuS7pM6HM=.36fca2c0-54a4-4563-b40a-c626bc7e1587@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

Per had an emacs feature to remove whitespaces at the end of the line, and gave me the vim version of that.  That's a nice feature.  I object to this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613437709

From rriggs at openjdk.org  Thu Jun 29 16:16:56 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 29 Jun 2023 16:16:56 GMT
Subject: RFR: 8311000: missing @since info in jdk.management
In-Reply-To: <-f8oRj4ThTKK-rAY9GnVSGlXrPLuIVcuz40dJBaFsF8=.fd87ccc0-858a-4e14-b2a4-d666faf1aa98@github.com>
References: <-f8oRj4ThTKK-rAY9GnVSGlXrPLuIVcuz40dJBaFsF8=.fd87ccc0-858a-4e14-b2a4-d666faf1aa98@github.com>
Message-ID: <FIYSjP7UWeIz_tPvWHepsvqpTCNDLriqR4aK3Uoe9os=.1cfb1a01-9210-425d-9970-fa07866f22f0@github.com>

On Thu, 29 Jun 2023 11:48:43 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Simple addition of a doc tag.  
> 
> src/share/classes/com/sun/management/GarbageCollectionNotificationInfo.java is introduced in jdk7 by
> 7036199: Adding a notification to the implementation of GarbageCollectorMXBeans

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14708#pullrequestreview-1505663793

From kevinw at openjdk.org  Thu Jun 29 16:19:04 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 29 Jun 2023 16:19:04 GMT
Subject: RFR: 8310988: Missing @since tags in java.management.rmi
Message-ID: <cB2TIYcNzqAJdO4UuK0iglDC2ygeVtWY8PQdqCj9A9A=.83398277-c955-4fc6-8a3f-55eb94d01419@github.com>

Simple doc tag addition.

These are files which describe an interface that has been with us since 1.5.  The files themselves were previously generated at build time, but have been in the repo since jdk15.  But the API is since 1.5.

The other file mentioned in the bug is not a public class and has no javadoc generated, ignoring that one.

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

Commit messages:
 - 8310988: Missing @since tags in java.management.rmi

Changes: https://git.openjdk.org/jdk/pull/14714/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14714&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310988
  Stats: 4 lines in 2 files changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14714.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14714/head:pull/14714

PR: https://git.openjdk.org/jdk/pull/14714

From rriggs at openjdk.org  Thu Jun 29 16:19:05 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 29 Jun 2023 16:19:05 GMT
Subject: RFR: 8310988: Missing @since tags in java.management.rmi
In-Reply-To: <cB2TIYcNzqAJdO4UuK0iglDC2ygeVtWY8PQdqCj9A9A=.83398277-c955-4fc6-8a3f-55eb94d01419@github.com>
References: <cB2TIYcNzqAJdO4UuK0iglDC2ygeVtWY8PQdqCj9A9A=.83398277-c955-4fc6-8a3f-55eb94d01419@github.com>
Message-ID: <ckUjl-w0ljbrJuZVbybH6x3PC7HoiSZioH8iedJi_9A=.d51b5927-eb50-496e-ba4b-01283240bc49@github.com>

On Thu, 29 Jun 2023 16:08:15 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Simple doc tag addition.
> 
> These are files which describe an interface that has been with us since 1.5.  The files themselves were previously generated at build time, but have been in the repo since jdk15.  But the API is since 1.5.
> 
> The other file mentioned in the bug is not a public class and has no javadoc generated, ignoring that one.

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14714#pullrequestreview-1505664161

From alanb at openjdk.org  Thu Jun 29 16:25:54 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 29 Jun 2023 16:25:54 GMT
Subject: RFR: 8310988: Missing @since tags in java.management.rmi
In-Reply-To: <cB2TIYcNzqAJdO4UuK0iglDC2ygeVtWY8PQdqCj9A9A=.83398277-c955-4fc6-8a3f-55eb94d01419@github.com>
References: <cB2TIYcNzqAJdO4UuK0iglDC2ygeVtWY8PQdqCj9A9A=.83398277-c955-4fc6-8a3f-55eb94d01419@github.com>
Message-ID: <lPccp0YtQKdl0QhYTnvBQWW_6YC1vUKJN4wgppZzukM=.e44c5b9a-cb5f-4147-b235-2b7961b0c63e@github.com>

On Thu, 29 Jun 2023 16:08:15 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Simple doc tag addition.
> 
> These are files which describe an interface that has been with us since 1.5.  The files themselves were previously generated at build time, but have been in the repo since jdk15.  But the API is since 1.5.
> 
> The other file mentioned in the bug is not a public class and has no javadoc generated, ignoring that one.

Looks fine, I assume you'll bump the copyright date before integrating.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14714#pullrequestreview-1505676832
PR Review: https://git.openjdk.org/jdk/pull/14714#pullrequestreview-1505677062

From kevinw at openjdk.org  Thu Jun 29 16:33:54 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 29 Jun 2023 16:33:54 GMT
Subject: RFR: 8310988: Missing @since tags in java.management.rmi
In-Reply-To: <lPccp0YtQKdl0QhYTnvBQWW_6YC1vUKJN4wgppZzukM=.e44c5b9a-cb5f-4147-b235-2b7961b0c63e@github.com>
References: <cB2TIYcNzqAJdO4UuK0iglDC2ygeVtWY8PQdqCj9A9A=.83398277-c955-4fc6-8a3f-55eb94d01419@github.com>
 <lPccp0YtQKdl0QhYTnvBQWW_6YC1vUKJN4wgppZzukM=.e44c5b9a-cb5f-4147-b235-2b7961b0c63e@github.com>
Message-ID: <2FQFhcetZQpuGxs636oYw_toe3BlsHGOq3a8QHzwKyI=.00bca7d5-a6b7-407e-9edd-3e6468852aa5@github.com>

On Thu, 29 Jun 2023 16:22:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Looks fine, I assume you'll bump the copyright date before integrating.

Will do.

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

PR Comment: https://git.openjdk.org/jdk/pull/14714#issuecomment-1613500142

From fparain at openjdk.org  Thu Jun 29 16:48:55 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 29 Jun 2023 16:48:55 GMT
Subject: RFR: 8311077: Fix -Wconversion warnings in jvmti code
In-Reply-To: <01jxrp1E-_5hGZ91QI0Og2XgbksXszXHWSzRiiuX9OM=.8d132e37-3821-4b48-a8e4-c3f2efb7b3ea@github.com>
References: <01jxrp1E-_5hGZ91QI0Og2XgbksXszXHWSzRiiuX9OM=.8d132e37-3821-4b48-a8e4-c3f2efb7b3ea@github.com>
Message-ID: <0XL-ZvygFTgVuhCgDTEfeXEjHZc9sqk23bMWheW1RUI=.f2812240-57fa-4d02-8148-6911c40daa56@github.com>

On Thu, 29 Jun 2023 12:17:23 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review change for mostly fixing return types in the constant pool and metadata to fix -Wconversion warnings in JVMTI code.  The order of preference for changes are: 1. change the types to more distinct types (fields in the constant pool are u2 because that's their size in the classfile), 2. add direct int casts if the value has been checked in asserts above, and 3. checked_cast<> if not verified, and 4. added some pointer_delta_as_ints where needed.
> Tested with tier1-4.

Marked as reviewed by fparain (Reviewer).

src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp line 399:

> 397:   int length = sizeof(u2); // num_bootstrap_methods
> 398:   for (int n = 0; n < num_bootstrap_methods; n++) {
> 399:     int num_bootstrap_arguments = cpool()->operand_argument_count_at(n);

operand_arguments_count_at() returns an u2, I think it would make more sense to put the cast line 402 where num_bootstrap_arguments is used.

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

PR Review: https://git.openjdk.org/jdk/pull/14710#pullrequestreview-1505437059
PR Review Comment: https://git.openjdk.org/jdk/pull/14710#discussion_r1246709628

From lkorinth at openjdk.org  Thu Jun 29 16:55:05 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 29 Jun 2023 16:55:05 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <azIQJToZ2tpGJTsICHpL96zs9mmHI3fW-laYwy3H-Xk=.99615245-24f9-4b95-b66d-eaba04c8318c@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

This was not liked, I will close it.

I will possibly do it under another PR for the GC code.

Thanks for reviewing.

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613526703

From lkorinth at openjdk.org  Thu Jun 29 16:55:06 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 29 Jun 2023 16:55:06 GMT
Subject: Withdrawn: 8311043: Remove trailing blank lines in source files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <Hsf1WhdMKL5I-3HmOkCZQJWI3MPIHPnFUpo_oMkZj6I=.1ca1f233-3eb8-4d1e-ae3e-eb19729dc1c9@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/14698

From coleenp at openjdk.org  Thu Jun 29 17:24:35 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 29 Jun 2023 17:24:35 GMT
Subject: RFR: 8311077: Fix -Wconversion warnings in jvmti code [v2]
In-Reply-To: <01jxrp1E-_5hGZ91QI0Og2XgbksXszXHWSzRiiuX9OM=.8d132e37-3821-4b48-a8e4-c3f2efb7b3ea@github.com>
References: <01jxrp1E-_5hGZ91QI0Og2XgbksXszXHWSzRiiuX9OM=.8d132e37-3821-4b48-a8e4-c3f2efb7b3ea@github.com>
Message-ID: <R9KAWXeTNBWXghU7yMWxrMzYgAcY2IW63-m7k_bO8xM=.fcc3eccc-56b1-4ddb-b442-8b7510f0c984@github.com>

> Please review change for mostly fixing return types in the constant pool and metadata to fix -Wconversion warnings in JVMTI code.  The order of preference for changes are: 1. change the types to more distinct types (fields in the constant pool are u2 because that's their size in the classfile), 2. add direct int casts if the value has been checked in asserts above, and 3. checked_cast<> if not verified, and 4. added some pointer_delta_as_ints where needed.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fred's comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14710/files
  - new: https://git.openjdk.org/jdk/pull/14710/files/325cd6e9..c77556da

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14710&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14710&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14710.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14710/head:pull/14710

PR: https://git.openjdk.org/jdk/pull/14710

From coleenp at openjdk.org  Thu Jun 29 17:24:38 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 29 Jun 2023 17:24:38 GMT
Subject: RFR: 8311077: Fix -Wconversion warnings in jvmti code [v2]
In-Reply-To: <0XL-ZvygFTgVuhCgDTEfeXEjHZc9sqk23bMWheW1RUI=.f2812240-57fa-4d02-8148-6911c40daa56@github.com>
References: <01jxrp1E-_5hGZ91QI0Og2XgbksXszXHWSzRiiuX9OM=.8d132e37-3821-4b48-a8e4-c3f2efb7b3ea@github.com>
 <0XL-ZvygFTgVuhCgDTEfeXEjHZc9sqk23bMWheW1RUI=.f2812240-57fa-4d02-8148-6911c40daa56@github.com>
Message-ID: <wj_AhkF00fls_jRyAnYMmoW6s7anqntkIgNbWDFTJ-8=.21d72149-964b-4455-ae80-a3c90291d60f@github.com>

On Thu, 29 Jun 2023 14:34:06 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fred's comments.
>
> src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp line 399:
> 
>> 397:   int length = sizeof(u2); // num_bootstrap_methods
>> 398:   for (int n = 0; n < num_bootstrap_methods; n++) {
>> 399:     int num_bootstrap_arguments = cpool()->operand_argument_count_at(n);
> 
> operand_arguments_count_at() returns an u2, I think it would make more sense to put the cast line 402 where num_bootstrap_arguments is used.

I fixed both things you noticed.  Thank you!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14710#discussion_r1246923278

From jjg at openjdk.org  Thu Jun 29 17:24:54 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 29 Jun 2023 17:24:54 GMT
Subject: RFR: 8310988: Missing @since tags in java.management.rmi
In-Reply-To: <cB2TIYcNzqAJdO4UuK0iglDC2ygeVtWY8PQdqCj9A9A=.83398277-c955-4fc6-8a3f-55eb94d01419@github.com>
References: <cB2TIYcNzqAJdO4UuK0iglDC2ygeVtWY8PQdqCj9A9A=.83398277-c955-4fc6-8a3f-55eb94d01419@github.com>
Message-ID: <ytUFGDO6JzoRWEHRLTHGT6ZsrckNEpUFXDhCpvhIcU8=.efde5de4-ad8c-4416-8f76-a3985dceae67@github.com>

On Thu, 29 Jun 2023 16:08:15 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Simple doc tag addition.
> 
> These are files which describe an interface that has been with us since 1.5.  The files themselves were previously generated at build time, but have been in the repo since jdk15.  But the API is since 1.5.
> 
> The other file mentioned in the bug is not a public class and has no javadoc generated, ignoring that one.

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14714#pullrequestreview-1505775865

From coleenp at openjdk.org  Thu Jun 29 17:29:50 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 29 Jun 2023 17:29:50 GMT
Subject: RFR: 8311077: Fix -Wconversion warnings in jvmti code [v3]
In-Reply-To: <01jxrp1E-_5hGZ91QI0Og2XgbksXszXHWSzRiiuX9OM=.8d132e37-3821-4b48-a8e4-c3f2efb7b3ea@github.com>
References: <01jxrp1E-_5hGZ91QI0Og2XgbksXszXHWSzRiiuX9OM=.8d132e37-3821-4b48-a8e4-c3f2efb7b3ea@github.com>
Message-ID: <mx5tJLlrj-p4MYD_519hWTOxKarSwS6zdgamH1UbLGc=.39a7e632-c1b6-4fec-8ddf-25d44fd5999f@github.com>

> Please review change for mostly fixing return types in the constant pool and metadata to fix -Wconversion warnings in JVMTI code.  The order of preference for changes are: 1. change the types to more distinct types (fields in the constant pool are u2 because that's their size in the classfile), 2. add direct int casts if the value has been checked in asserts above, and 3. checked_cast<> if not verified, and 4. added some pointer_delta_as_ints where needed.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Add a comment about u1 cast to new_index for the ldc bytecode.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14710/files
  - new: https://git.openjdk.org/jdk/pull/14710/files/c77556da..42781421

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14710&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14710&range=01-02

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14710.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14710/head:pull/14710

PR: https://git.openjdk.org/jdk/pull/14710

From matsaave at openjdk.org  Thu Jun 29 17:37:59 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 29 Jun 2023 17:37:59 GMT
Subject: RFR: 8311077: Fix -Wconversion warnings in jvmti code [v3]
In-Reply-To: <mx5tJLlrj-p4MYD_519hWTOxKarSwS6zdgamH1UbLGc=.39a7e632-c1b6-4fec-8ddf-25d44fd5999f@github.com>
References: <01jxrp1E-_5hGZ91QI0Og2XgbksXszXHWSzRiiuX9OM=.8d132e37-3821-4b48-a8e4-c3f2efb7b3ea@github.com>
 <mx5tJLlrj-p4MYD_519hWTOxKarSwS6zdgamH1UbLGc=.39a7e632-c1b6-4fec-8ddf-25d44fd5999f@github.com>
Message-ID: <AODogPLCAAAChm1r4MTmDgqJw5Sd5iPsKZhSBVljBWU=.edc16278-06db-462a-875f-9be87d167c82@github.com>

On Thu, 29 Jun 2023 17:29:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review change for mostly fixing return types in the constant pool and metadata to fix -Wconversion warnings in JVMTI code.  The order of preference for changes are: 1. change the types to more distinct types (fields in the constant pool are u2 because that's their size in the classfile), 2. add direct int casts if the value has been checked in asserts above, and 3. checked_cast<> if not verified, and 4. added some pointer_delta_as_ints where needed.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a comment about u1 cast to new_index for the ldc bytecode.

Looks good, thanks for this change! I listed a few considerations below, but if you don't think they are necessary, what you have is just fine.

src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 2195:

> 2193:       case Bytecodes::_ldc:
> 2194:       {
> 2195:         u1 cp_index = *(bcp + 1);

Constant pool indices are usually u2, why does this need to be a u1?

src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 2268:

> 2266:       {
> 2267:         address p = bcp + 1;
> 2268:         int cp_index = Bytes::get_Java_u2(p);

Should this field also be a u2?

src/hotspot/share/prims/methodComparator.cpp line 79:

> 77:   case Bytecodes::_instanceof     : {
> 78:     int cpi_old = s_old->get_index_u2();
> 79:     int cpi_new = s_new->get_index_u2();

These constant pool accessors like `klass_at_noresolve` currently take in `int which` but I think it's worth looking at if this is necessary. Constant pool indices and constant pool cache indices seem to both be u2 so it might be a better option to change the arguments to u2 here to avoid the need to cast.

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

Marked as reviewed by matsaave (Committer).

PR Review: https://git.openjdk.org/jdk/pull/14710#pullrequestreview-1505776921
PR Review Comment: https://git.openjdk.org/jdk/pull/14710#discussion_r1246928389
PR Review Comment: https://git.openjdk.org/jdk/pull/14710#discussion_r1246927933
PR Review Comment: https://git.openjdk.org/jdk/pull/14710#discussion_r1246934498

From amenkov at openjdk.org  Thu Jun 29 18:40:50 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 29 Jun 2023 18:40:50 GMT
Subject: RFR: JDK-8310066: Improve test coverage for JVMTI GetThreadState
 on carrier and mounted vthread [v4]
In-Reply-To: <_8UnxXrT842BKmJ98GlmJyL21yzM0dhGOkeeK0Mnf2g=.c90b2826-922c-4838-b816-8bf3b5933d87@github.com>
References: <_8UnxXrT842BKmJ98GlmJyL21yzM0dhGOkeeK0Mnf2g=.c90b2826-922c-4838-b816-8bf3b5933d87@github.com>
Message-ID: <-FrKWOC5k2JpNUEIZBqUUJk_giziAJ6PWypcG54IdSg=.abbb5539-fb96-40c0-92ec-ac55553ba50b@github.com>

> This is follow-up JDK-8307153/JDK-8309612 (JVMTI GetThreadState on carrier should return STATE_WAITING)
> New test tests GetThreadState for different thread states.
> The test detected a bug in the implementation, new issue is created: JDK-8310584
> Corresponding testcases are commented now in the test, fix for JDK-8310584 will uncomment them

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  updated comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14622/files
  - new: https://git.openjdk.org/jdk/pull/14622/files/6c517cef..8918411b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14622&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14622&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14622.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14622/head:pull/14622

PR: https://git.openjdk.org/jdk/pull/14622

From amenkov at openjdk.org  Thu Jun 29 18:40:54 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 29 Jun 2023 18:40:54 GMT
Subject: RFR: JDK-8310066: Improve test coverage for JVMTI GetThreadState
 on carrier and mounted vthread [v3]
In-Reply-To: <tV7aHhjwSGiNDrnMHVcx6aea2BCUEZJg-7DmR5I4iy8=.de110fe0-6b99-4310-a2f8-1ecc37c6e856@github.com>
References: <_8UnxXrT842BKmJ98GlmJyL21yzM0dhGOkeeK0Mnf2g=.c90b2826-922c-4838-b816-8bf3b5933d87@github.com>
 <VInLWm0-r-6j7reX915h7M5XdRsml4r-XWvyoLxYN54=.f58a427f-95a8-4190-b7ff-804a564197ef@github.com>
 <tV7aHhjwSGiNDrnMHVcx6aea2BCUEZJg-7DmR5I4iy8=.de110fe0-6b99-4310-a2f8-1ecc37c6e856@github.com>
Message-ID: <KKn3ZE1kKabeBdeyNFiYqFn7QBSkbdS48FLQL1Bz1HA=.42256c35-1ddc-4a31-a3e4-a9204eb0e98f@github.com>

On Thu, 29 Jun 2023 14:10:38 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   spurious wakeups
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadStateMountedTest/GetThreadStateMountedTest.java line 41:
> 
>> 39: /**
>> 40:  * The test implements different scenarios to get desired JVMTI thread states.
>> 41:  * For each scenarios test also checks states after carrier and virtual threads suspend/resume
> 
> Nit: `each scenarios` => `each scenario`

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14622#discussion_r1246974900

From amenkov at openjdk.org  Thu Jun 29 18:53:51 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 29 Jun 2023 18:53:51 GMT
Subject: RFR: JDK-8310066: Improve test coverage for JVMTI GetThreadState
 on carrier and mounted vthread [v3]
In-Reply-To: <AFhGb86TenuURRlW7F805T_qXAwCRu1C--8r40VW6uU=.bdbac40d-78ff-4cd1-a4fa-fe6f337e931b@github.com>
References: <_8UnxXrT842BKmJ98GlmJyL21yzM0dhGOkeeK0Mnf2g=.c90b2826-922c-4838-b816-8bf3b5933d87@github.com>
 <VInLWm0-r-6j7reX915h7M5XdRsml4r-XWvyoLxYN54=.f58a427f-95a8-4190-b7ff-804a564197ef@github.com>
 <AFhGb86TenuURRlW7F805T_qXAwCRu1C--8r40VW6uU=.bdbac40d-78ff-4cd1-a4fa-fe6f337e931b@github.com>
Message-ID: <uuXihGQGZ7kjPnl8lw-gRzvX8uva2R0y_nC-2cbeWx0=.84453863-96d0-4d1b-929e-208bd577716e@github.com>

On Thu, 29 Jun 2023 14:26:10 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   spurious wakeups
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadStateMountedTest/GetThreadStateMountedTest.java line 62:
> 
>> 60:         TestStatus status = new TestStatus("JVMTI_THREAD_STATE_RUNNABLE");
>> 61:         CountDownLatch ready = new CountDownLatch(1);
>> 62:         final boolean[] stopFlag = new boolean[1];
> 
> Q: It is not clear why an array is needed instead of non-final local. The same question for `waiting()` method below. I'm thinking if reverting the flag to something like `needContinue` would simplify code a little bit.

It's used in lambda, so must be final
I think both "flag to stop" and "flag to continue" are clear, I prefer "flag to stop" as it does not require additional initialization

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14622#discussion_r1246990707

From coleenp at openjdk.org  Thu Jun 29 19:57:55 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 29 Jun 2023 19:57:55 GMT
Subject: RFR: 8311077: Fix -Wconversion warnings in jvmti code [v3]
In-Reply-To: <mx5tJLlrj-p4MYD_519hWTOxKarSwS6zdgamH1UbLGc=.39a7e632-c1b6-4fec-8ddf-25d44fd5999f@github.com>
References: <01jxrp1E-_5hGZ91QI0Og2XgbksXszXHWSzRiiuX9OM=.8d132e37-3821-4b48-a8e4-c3f2efb7b3ea@github.com>
 <mx5tJLlrj-p4MYD_519hWTOxKarSwS6zdgamH1UbLGc=.39a7e632-c1b6-4fec-8ddf-25d44fd5999f@github.com>
Message-ID: <-QQPx1FGcV6uasVLT7ZleHLPjElg32n4IVKlDDHqKB8=.de670991-a23c-4b48-a896-02bed6355838@github.com>

On Thu, 29 Jun 2023 17:29:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review change for mostly fixing return types in the constant pool and metadata to fix -Wconversion warnings in JVMTI code.  The order of preference for changes are: 1. change the types to more distinct types (fields in the constant pool are u2 because that's their size in the classfile), 2. add direct int casts if the value has been checked in asserts above, and 3. checked_cast<> if not verified, and 4. added some pointer_delta_as_ints where needed.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a comment about u1 cast to new_index for the ldc bytecode.

Thanks for your comments Matias.  Some of the changes that I didn't make were because Wconversion didn't complain and where I could avoid casting.  I think more precise types for constant pool indices and cpCache indices might be more pervasive than we want and might cause more warnings down the line.  So I avoided them.

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

PR Review: https://git.openjdk.org/jdk/pull/14710#pullrequestreview-1505961331

From coleenp at openjdk.org  Thu Jun 29 19:57:59 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 29 Jun 2023 19:57:59 GMT
Subject: RFR: 8311077: Fix -Wconversion warnings in jvmti code [v3]
In-Reply-To: <AODogPLCAAAChm1r4MTmDgqJw5Sd5iPsKZhSBVljBWU=.edc16278-06db-462a-875f-9be87d167c82@github.com>
References: <01jxrp1E-_5hGZ91QI0Og2XgbksXszXHWSzRiiuX9OM=.8d132e37-3821-4b48-a8e4-c3f2efb7b3ea@github.com>
 <mx5tJLlrj-p4MYD_519hWTOxKarSwS6zdgamH1UbLGc=.39a7e632-c1b6-4fec-8ddf-25d44fd5999f@github.com>
 <AODogPLCAAAChm1r4MTmDgqJw5Sd5iPsKZhSBVljBWU=.edc16278-06db-462a-875f-9be87d167c82@github.com>
Message-ID: <yZTvD0jWS2D6MQ2K5-GuuVz7QbmPMoe7S0DE8KqV8b0=.a37a1ebe-2344-4238-a7b5-05141d9ef2d3@github.com>

On Thu, 29 Jun 2023 17:23:44 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add a comment about u1 cast to new_index for the ldc bytecode.
>
> src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 2195:
> 
>> 2193:       case Bytecodes::_ldc:
>> 2194:       {
>> 2195:         u1 cp_index = *(bcp + 1);
> 
> Constant pool indices are usually u2, why does this need to be a u1?

This could be a u2 to avoid confusion.  Since it's ldc, the cp_index in the ldc bytecode is only a u1 but this didn't get a Wconversion error so I should probably keep it as int.

> src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 2268:
> 
>> 2266:       {
>> 2267:         address p = bcp + 1;
>> 2268:         int cp_index = Bytes::get_Java_u2(p);
> 
> Should this field also be a u2?

It could be a u2, but since find_new_index's parameter is int and didn't need a cast further down, I didn't change it to one.

> src/hotspot/share/prims/methodComparator.cpp line 79:
> 
>> 77:   case Bytecodes::_instanceof     : {
>> 78:     int cpi_old = s_old->get_index_u2();
>> 79:     int cpi_new = s_new->get_index_u2();
> 
> These constant pool accessors like `klass_at_noresolve` currently take in `int which` but I think it's worth looking at if this is necessary. Constant pool indices and constant pool cache indices seem to both be u2 so it might be a better option to change the arguments to u2 here to avoid the need to cast.

I had to change these two lines because BytecodeStream::get_index_u2 returns an int, so got the warning and this didn't need to be declared with u2.  get_index_u2() could be fixed to return a u2 but I didn't want to go that far as no casts were involved in this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14710#discussion_r1247101683
PR Review Comment: https://git.openjdk.org/jdk/pull/14710#discussion_r1247069649
PR Review Comment: https://git.openjdk.org/jdk/pull/14710#discussion_r1247053822

From dnsimon at openjdk.org  Thu Jun 29 20:06:19 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 29 Jun 2023 20:06:19 GMT
Subject: RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit [v6]
In-Reply-To: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
References: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
Message-ID: <PAmaIcD3QoUOkp-XmZG2uhkLgvyJs8altN90PoW4pB4=.37f7fa52-fc02-48b7-9cae-0ed3edc23ed4@github.com>

> The VMSupport class is required for translating an exception between the HotSpot and libgraal heaps.
> Loading it lazily can result in a loading exception, obscuring the exception being translated.
> To avoid this, VMSupport is loaded eagerly along with the other vmClasses.

Doug Simon 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:

 - [skip ci] Merge remote-tracking branch 'openjdk-jdk/master' into JDK-8310829
 - [skip ci] handle pending HotSpot exception closer to site causing exception
 - revert to lazy loading of VMSupport
 - each exception translation failure should trigger a JVMCI event
 - try harder to show nested exception during exception translation
 - resolve VMSupport at bootstrap to avoid nested exception in ExceptionTranslation::doit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14641/files
  - new: https://git.openjdk.org/jdk/pull/14641/files/9236128a..e46a6a17

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14641&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14641&range=04-05

  Stats: 13222 lines in 537 files changed: 6305 ins; 3442 del; 3475 mod
  Patch: https://git.openjdk.org/jdk/pull/14641.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14641/head:pull/14641

PR: https://git.openjdk.org/jdk/pull/14641

From dnsimon at openjdk.org  Thu Jun 29 20:06:20 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 29 Jun 2023 20:06:20 GMT
Subject: RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit [v5]
In-Reply-To: <2UadNxsZ2qr29Z5jPOyIQTNgjvTGY_7hRpr8W8UDYBE=.4b83127f-5258-4ef1-93dd-7460aa514adc@github.com>
References: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
 <Am7TNzGn_KTfxFEIV_ytEFYckL7Bvp_oqRYAGA5eT38=.794dff2b-7508-496e-9857-e03175c77ebf@github.com>
 <2UadNxsZ2qr29Z5jPOyIQTNgjvTGY_7hRpr8W8UDYBE=.4b83127f-5258-4ef1-93dd-7460aa514adc@github.com>
Message-ID: <JuqoonAAjgojII-n87MpLarTd-iXrWdBcXVULDmNrks=.5c9a2594-56ac-45c4-9292-05e1865f51d9@github.com>

On Thu, 29 Jun 2023 02:13:32 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Someone from the compiler team should review this now.

@vnkozlov could you please review this or nominate someone else from the compiler team to look at it. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/14641#issuecomment-1613736704

From kvn at openjdk.org  Thu Jun 29 23:59:57 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 29 Jun 2023 23:59:57 GMT
Subject: RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit [v6]
In-Reply-To: <PAmaIcD3QoUOkp-XmZG2uhkLgvyJs8altN90PoW4pB4=.37f7fa52-fc02-48b7-9cae-0ed3edc23ed4@github.com>
References: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
 <PAmaIcD3QoUOkp-XmZG2uhkLgvyJs8altN90PoW4pB4=.37f7fa52-fc02-48b7-9cae-0ed3edc23ed4@github.com>
Message-ID: <WLuieiZ-OnjHS_Lkb4Mr2aJQnGRxCnI9E5dBCGoe9wQ=.14980283-057a-4a86-bbe0-b3c26be1ec4f@github.com>

On Thu, 29 Jun 2023 20:06:19 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> The VMSupport class is required for translating an exception between the HotSpot and libgraal heaps.
>> Loading it lazily can result in a loading exception, obscuring the exception being translated.
>> To avoid this, VMSupport is loaded eagerly along with the other vmClasses.
>
> Doug Simon 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:
> 
>  - [skip ci] Merge remote-tracking branch 'openjdk-jdk/master' into JDK-8310829
>  - [skip ci] handle pending HotSpot exception closer to site causing exception
>  - revert to lazy loading of VMSupport
>  - each exception translation failure should trigger a JVMCI event
>  - try harder to show nested exception during exception translation
>  - resolve VMSupport at bootstrap to avoid nested exception in ExceptionTranslation::doit

I am fins with idea of changes. But, please, activate GHA testing for this branch.
And there is build error on Windows:

c:\workspace\open\src\hotspot\share\jvmci\jvmciEnv.cpp(449): error C2220: the following warning is treated as an error
c:\workspace\open\src\hotspot\share\jvmci\jvmciEnv.cpp(449): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data

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

PR Comment: https://git.openjdk.org/jdk/pull/14641#issuecomment-1613932794

From dholmes at openjdk.org  Fri Jun 30 01:24:05 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 30 Jun 2023 01:24:05 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <jLa8PV1GIQpbUHJVsxcmv8B6osgOh6Gl--cFTsxxQRE=.037e8a3c-080a-4dce-bf14-b63779c34fd3@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
 <3rq9p7Pqn9UcVlQ5E0XMltGBBgmpWeLiz0k7HDi53qE=.fa670ef1-cd6c-4e4a-9ec3-89d5a2fec0ef@github.com>
 <jLa8PV1GIQpbUHJVsxcmv8B6osgOh6Gl--cFTsxxQRE=.037e8a3c-080a-4dce-bf14-b63779c34fd3@github.com>
Message-ID: <ufj18ITz-S_VgkscmrxacxLtfQB-4I5hpgs8c61kOmA=.15f34364-70ac-4279-8669-f01e109b8411@github.com>

On Thu, 29 Jun 2023 13:05:58 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> My changes look like this in the diff output
> ```
>  }
> -
> ```

Thanks for showing  this and other output. To me this looked like the final newline had been removed. I would have expected to see something that more obviously showed more than one blank line before hand and exactly one after.

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1613985636

From sspitsyn at openjdk.org  Fri Jun 30 01:47:58 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 30 Jun 2023 01:47:58 GMT
Subject: RFR: JDK-8310066: Improve test coverage for JVMTI GetThreadState
 on carrier and mounted vthread [v3]
In-Reply-To: <uuXihGQGZ7kjPnl8lw-gRzvX8uva2R0y_nC-2cbeWx0=.84453863-96d0-4d1b-929e-208bd577716e@github.com>
References: <_8UnxXrT842BKmJ98GlmJyL21yzM0dhGOkeeK0Mnf2g=.c90b2826-922c-4838-b816-8bf3b5933d87@github.com>
 <VInLWm0-r-6j7reX915h7M5XdRsml4r-XWvyoLxYN54=.f58a427f-95a8-4190-b7ff-804a564197ef@github.com>
 <AFhGb86TenuURRlW7F805T_qXAwCRu1C--8r40VW6uU=.bdbac40d-78ff-4cd1-a4fa-fe6f337e931b@github.com>
 <uuXihGQGZ7kjPnl8lw-gRzvX8uva2R0y_nC-2cbeWx0=.84453863-96d0-4d1b-929e-208bd577716e@github.com>
Message-ID: <TkStYiuLpdB4Ej-_mhBCYXT-lOh-tJmVsarY_oxOVDQ=.221d295a-a6d7-4998-aaee-d3c1ed1aff03@github.com>

On Thu, 29 Jun 2023 18:51:26 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadStateMountedTest/GetThreadStateMountedTest.java line 62:
>> 
>>> 60:         TestStatus status = new TestStatus("JVMTI_THREAD_STATE_RUNNABLE");
>>> 61:         CountDownLatch ready = new CountDownLatch(1);
>>> 62:         final boolean[] stopFlag = new boolean[1];
>> 
>> Q: It is not clear why an array is needed instead of non-final local. The same question for `waiting()` method below. I'm thinking if reverting the flag to something like `needContinue` would simplify code a little bit.
>
> It's used in lambda, so must be final
> I think both "flag to stop" and "flag to continue" are clear, I prefer "flag to stop" as it does not require additional initialization

Okay, I see why an array is needed.
It is really minor and up to you. Just wanted to get rid of one negation. :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14622#discussion_r1247319839

From dholmes at openjdk.org  Fri Jun 30 01:53:05 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 30 Jun 2023 01:53:05 GMT
Subject: RFR: 8311077: Fix -Wconversion warnings in jvmti code [v3]
In-Reply-To: <yZTvD0jWS2D6MQ2K5-GuuVz7QbmPMoe7S0DE8KqV8b0=.a37a1ebe-2344-4238-a7b5-05141d9ef2d3@github.com>
References: <01jxrp1E-_5hGZ91QI0Og2XgbksXszXHWSzRiiuX9OM=.8d132e37-3821-4b48-a8e4-c3f2efb7b3ea@github.com>
 <mx5tJLlrj-p4MYD_519hWTOxKarSwS6zdgamH1UbLGc=.39a7e632-c1b6-4fec-8ddf-25d44fd5999f@github.com>
 <AODogPLCAAAChm1r4MTmDgqJw5Sd5iPsKZhSBVljBWU=.edc16278-06db-462a-875f-9be87d167c82@github.com>
 <yZTvD0jWS2D6MQ2K5-GuuVz7QbmPMoe7S0DE8KqV8b0=.a37a1ebe-2344-4238-a7b5-05141d9ef2d3@github.com>
Message-ID: <pqwh6JgqVQpd_Q0tYm4D_Z5Bl1bjnqIWFIxIUcGpzko=.399ca163-f1a6-4df6-80b0-98f831417787@github.com>

On Thu, 29 Jun 2023 19:51:43 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 2195:
>> 
>>> 2193:       case Bytecodes::_ldc:
>>> 2194:       {
>>> 2195:         u1 cp_index = *(bcp + 1);
>> 
>> Constant pool indices are usually u2, why does this need to be a u1?
>
> This could be a u2 to avoid confusion.  Since it's ldc, the cp_index in the ldc bytecode is only a u1 but this didn't get a Wconversion error so I should probably keep it as int.
> Edit: the bcp offset fetched is a u1 (byte) size, but we assign cp_index into new_index below so cp_index needs to be smaller than new_index.  That's why I changed it.  Making it u1 is more precise and doesn't have warnings.

I agree - using u1 to match the spec is a good thing here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14710#discussion_r1247322728

From dholmes at openjdk.org  Fri Jun 30 02:21:03 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 30 Jun 2023 02:21:03 GMT
Subject: RFR: 8311077: Fix -Wconversion warnings in jvmti code [v3]
In-Reply-To: <mx5tJLlrj-p4MYD_519hWTOxKarSwS6zdgamH1UbLGc=.39a7e632-c1b6-4fec-8ddf-25d44fd5999f@github.com>
References: <01jxrp1E-_5hGZ91QI0Og2XgbksXszXHWSzRiiuX9OM=.8d132e37-3821-4b48-a8e4-c3f2efb7b3ea@github.com>
 <mx5tJLlrj-p4MYD_519hWTOxKarSwS6zdgamH1UbLGc=.39a7e632-c1b6-4fec-8ddf-25d44fd5999f@github.com>
Message-ID: <wl6xt8GqBTcLHud-BstO5uw2EfbKNpwtqWRv-aYVJu0=.318f70a0-c88e-43ad-ade4-35148e9c7715@github.com>

On Thu, 29 Jun 2023 17:29:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review change for mostly fixing return types in the constant pool and metadata to fix -Wconversion warnings in JVMTI code.  The order of preference for changes are: 1. change the types to more distinct types (fields in the constant pool are u2 because that's their size in the classfile), 2. add direct int casts if the value has been checked in asserts above, and 3. checked_cast<> if not verified, and 4. added some pointer_delta_as_ints where needed.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a comment about u1 cast to new_index for the ldc bytecode.

Sorry Coleen but this raises a lot of questions for me. I expect there are a few ways to silence these conversion warnings but many of the proposed changes don't look semantically right to me. I realize that we have a lot of inconsistencies in the way we declare and use types and that the proposed changes may be the most minimal way to fix things, but it is better to type them correctly from the start IMO and only cast at the "boundaries" if it requires a change to propagate too far.

src/hotspot/share/oops/constMethod.hpp line 327:

> 325: 
> 326:   // code size
> 327:   u2 code_size() const                          { return _code_size; }

The `code_length` of a `Code` attribute is `u4` - why is `u2` appropriate here?

src/hotspot/share/oops/method.hpp line 257:

> 255: 
> 256:   // code size
> 257:   u2 code_size() const                   { return constMethod()->code_size(); }

Again why is this not u4?

src/hotspot/share/oops/method.hpp line 269:

> 267:   // return original max stack size for method verification
> 268:   u2  verifier_max_stack() const               { return constMethod()->max_stack(); }
> 269:   int          max_stack() const               { return constMethod()->max_stack() + extra_stack_entries(); }

So this has to be greater than a `u2` because of the extra entries?

src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp line 310:

> 308:   write_attribute_name_index("MethodParameters");
> 309:   write_u4(size);
> 310:   write_u1((u1)length);

What is the rule for using a plain cast versus a checked_cast?

src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp line 402:

> 400:     length += sizeof(u2); // bootstrap_method_ref
> 401:     length += sizeof(u2); // num_bootstrap_arguments
> 402:     length += (int)sizeof(u2) * num_bootstrap_arguments; // bootstrap_arguments[num_bootstrap_arguments]

Not clear why the int cast is used given length is a u4?

src/hotspot/share/prims/jvmtiRawMonitor.cpp line 83:

> 81: bool
> 82: JvmtiRawMonitor::is_valid() {
> 83:   uint64_t value = 0;

Why `uint64_t` here when `JvmtiEnvBase::is_valid` uses `jlong`?

src/hotspot/share/prims/jvmtiRawMonitor.cpp line 385:

> 383:   OrderAccess::fence();
> 384: 
> 385:   int save = _recursions;

`_recursions` is `intx`

src/hotspot/share/prims/jvmtiTrace.cpp line 205:

> 203:               _trace_flags[i] |= bits;
> 204:             } else {
> 205:               _trace_flags[i] &= (jbyte)~bits;

Looks strange that only this use of bits needs the cast?

src/hotspot/share/prims/jvmtiTrace.cpp line 234:

> 232:             _event_trace_flags[i] |= bits;
> 233:           } else {
> 234:             _event_trace_flags[i] &= (jbyte)~bits;

Looks strange that only this use of bits needs the cast?

src/hotspot/share/runtime/jfieldIDWorkaround.hpp line 87:

> 85:     return ((as_uint & checked_mask_in_place) != 0);
> 86:   }
> 87:   static int raw_instance_offset(jfieldID id) {

This doesn't look right as we've gone from returning a 64-bit value to a 32-bit value. If it is meant to be only 32-bit I expect the callers need some adjustment too.

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

PR Review: https://git.openjdk.org/jdk/pull/14710#pullrequestreview-1506346034
PR Review Comment: https://git.openjdk.org/jdk/pull/14710#discussion_r1247323647
PR Review Comment: https://git.openjdk.org/jdk/pull/14710#discussion_r1247326196
PR Review Comment: https://git.openjdk.org/jdk/pull/14710#discussion_r1247326799
PR Review Comment: https://git.openjdk.org/jdk/pull/14710#discussion_r1247328384
PR Review Comment: https://git.openjdk.org/jdk/pull/14710#discussion_r1247329307
PR Review Comment: https://git.openjdk.org/jdk/pull/14710#discussion_r1247332160
PR Review Comment: https://git.openjdk.org/jdk/pull/14710#discussion_r1247332571
PR Review Comment: https://git.openjdk.org/jdk/pull/14710#discussion_r1247333138
PR Review Comment: https://git.openjdk.org/jdk/pull/14710#discussion_r1247333184
PR Review Comment: https://git.openjdk.org/jdk/pull/14710#discussion_r1247334731

From dholmes at openjdk.org  Fri Jun 30 02:21:06 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 30 Jun 2023 02:21:06 GMT
Subject: RFR: 8311077: Fix -Wconversion warnings in jvmti code [v3]
In-Reply-To: <yZTvD0jWS2D6MQ2K5-GuuVz7QbmPMoe7S0DE8KqV8b0=.a37a1ebe-2344-4238-a7b5-05141d9ef2d3@github.com>
References: <01jxrp1E-_5hGZ91QI0Og2XgbksXszXHWSzRiiuX9OM=.8d132e37-3821-4b48-a8e4-c3f2efb7b3ea@github.com>
 <mx5tJLlrj-p4MYD_519hWTOxKarSwS6zdgamH1UbLGc=.39a7e632-c1b6-4fec-8ddf-25d44fd5999f@github.com>
 <AODogPLCAAAChm1r4MTmDgqJw5Sd5iPsKZhSBVljBWU=.edc16278-06db-462a-875f-9be87d167c82@github.com>
 <yZTvD0jWS2D6MQ2K5-GuuVz7QbmPMoe7S0DE8KqV8b0=.a37a1ebe-2344-4238-a7b5-05141d9ef2d3@github.com>
Message-ID: <1838l9S8X7CSCeDdkqjsEUPSW1A8dgKD3xjXmqmdQPg=.5756c1a3-8590-451e-a565-62b1cd1dc34e@github.com>

On Thu, 29 Jun 2023 19:44:58 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/prims/methodComparator.cpp line 79:
>> 
>>> 77:   case Bytecodes::_instanceof     : {
>>> 78:     int cpi_old = s_old->get_index_u2();
>>> 79:     int cpi_new = s_new->get_index_u2();
>> 
>> These constant pool accessors like `klass_at_noresolve` currently take in `int which` but I think it's worth looking at if this is necessary. Constant pool indices and constant pool cache indices seem to both be u2 so it might be a better option to change the arguments to u2 here to avoid the need to cast.
>
> I had to change these two lines because BytecodeStream::get_index_u2 returns an int, so got the warning and this didn't need to be declared with u2.  get_index_u2() could be fixed to return a u2 but I didn't want to go that far as no casts were involved in this change.

I think this change looks "wrong" - the indices are supposed to be u2's, if the function returns an int that seems an error.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14710#discussion_r1247334013

From sspitsyn at openjdk.org  Fri Jun 30 05:58:54 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 30 Jun 2023 05:58:54 GMT
Subject: RFR: JDK-8310066: Improve test coverage for JVMTI GetThreadState
 on carrier and mounted vthread [v4]
In-Reply-To: <-FrKWOC5k2JpNUEIZBqUUJk_giziAJ6PWypcG54IdSg=.abbb5539-fb96-40c0-92ec-ac55553ba50b@github.com>
References: <_8UnxXrT842BKmJ98GlmJyL21yzM0dhGOkeeK0Mnf2g=.c90b2826-922c-4838-b816-8bf3b5933d87@github.com>
 <-FrKWOC5k2JpNUEIZBqUUJk_giziAJ6PWypcG54IdSg=.abbb5539-fb96-40c0-92ec-ac55553ba50b@github.com>
Message-ID: <drX8F0cME_toOtXHddOHAob3pT0v1rCjUpA8QxmEoxY=.03a7d4a3-6526-42b5-b515-bb075d4c664e@github.com>

On Thu, 29 Jun 2023 18:40:50 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> This is follow-up JDK-8307153/JDK-8309612 (JVMTI GetThreadState on carrier should return STATE_WAITING)
>> New test tests GetThreadState for different thread states.
>> The test detected a bug in the implementation, new issue is created: JDK-8310584
>> Corresponding testcases are commented now in the test, fix for JDK-8310584 will uncomment them
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated comment

Thank you for the test. It is nice to have it.
It looks good.
Thanks,
Serguei

test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadStateMountedTest/libGetThreadStateMountedTest.cpp line 112:

> 110:       LOG("  ERROR: all expected 'weak' bits are set\n");
> 111:     }
> 112:   }

Nit: I guess, error message at line 110 has to be: 
`ERROR: not all expected 'weak' bits are set`
Also, it looks like the check 3a is not really needed as the 3b should cover it.
But I leave it up to you, if you think check 3a gives some convenience.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14622#pullrequestreview-1506557170
PR Review Comment: https://git.openjdk.org/jdk/pull/14622#discussion_r1247465477

From mli at openjdk.org  Fri Jun 30 06:40:52 2023
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 30 Jun 2023 06:40:52 GMT
Subject: RFR: 8310988: Missing @since tags in java.management.rmi
In-Reply-To: <cB2TIYcNzqAJdO4UuK0iglDC2ygeVtWY8PQdqCj9A9A=.83398277-c955-4fc6-8a3f-55eb94d01419@github.com>
References: <cB2TIYcNzqAJdO4UuK0iglDC2ygeVtWY8PQdqCj9A9A=.83398277-c955-4fc6-8a3f-55eb94d01419@github.com>
Message-ID: <ygSBqpQc6Q1HaAX1ejej-v9reOLE1GG2qYpDDu7IdRY=.a5582c2b-f13b-49e7-b192-cdf3f3239049@github.com>

On Thu, 29 Jun 2023 16:08:15 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Simple doc tag addition.
> 
> These are files which describe an interface that has been with us since 1.5.  The files themselves were previously generated at build time, but have been in the repo since jdk15.  But the API is since 1.5.
> 
> The other file mentioned in the bug is not a public class and has no javadoc generated, ignoring that one.

Marked as reviewed by mli (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14714#pullrequestreview-1506598416

From mli at openjdk.org  Fri Jun 30 06:43:53 2023
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 30 Jun 2023 06:43:53 GMT
Subject: RFR: 8311000: missing @since info in jdk.management
In-Reply-To: <-f8oRj4ThTKK-rAY9GnVSGlXrPLuIVcuz40dJBaFsF8=.fd87ccc0-858a-4e14-b2a4-d666faf1aa98@github.com>
References: <-f8oRj4ThTKK-rAY9GnVSGlXrPLuIVcuz40dJBaFsF8=.fd87ccc0-858a-4e14-b2a4-d666faf1aa98@github.com>
Message-ID: <i4XH6KETQ39ThVqANcNHFxwK3J0c7ycQoQBgb5uvHsU=.ee483d88-8146-475c-81be-248d0b852cf9@github.com>

On Thu, 29 Jun 2023 11:48:43 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Simple addition of a doc tag.  
> 
> src/share/classes/com/sun/management/GarbageCollectionNotificationInfo.java is introduced in jdk7 by
> 7036199: Adding a notification to the implementation of GarbageCollectorMXBeans

Marked as reviewed by mli (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14708#pullrequestreview-1506600934

From mbaesken at openjdk.org  Fri Jun 30 08:19:08 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 30 Jun 2023 08:19:08 GMT
Subject: RFR: JDK-8311026: Some G1 specific tests do not set -XX:+UseG1GC
Message-ID: <oUHMIq8zmo_V85u0_aClADgteBsHEZCfLhk9rj-KPeU=.64545793-07de-454d-8b32-23774bd2c095@github.com>

Most G1 tests set -XX:+UseG1GC, but a few (e.g. gc/g1/TestVerificationInConcurrentCycle.java) miss that.
This is usually just fine and no problem because G1 is the default anyway.
However in some cases, where a custom JVM changes the default GC, those tests start to fail which is not really necessary.

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

Commit messages:
 - JDK-8311026

Changes: https://git.openjdk.org/jdk/pull/14722/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14722&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311026
  Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14722.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14722/head:pull/14722

PR: https://git.openjdk.org/jdk/pull/14722

From sspitsyn at openjdk.org  Fri Jun 30 08:29:07 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 30 Jun 2023 08:29:07 GMT
Subject: RFR: JDK-8311026: Some G1 specific tests do not set -XX:+UseG1GC
In-Reply-To: <oUHMIq8zmo_V85u0_aClADgteBsHEZCfLhk9rj-KPeU=.64545793-07de-454d-8b32-23774bd2c095@github.com>
References: <oUHMIq8zmo_V85u0_aClADgteBsHEZCfLhk9rj-KPeU=.64545793-07de-454d-8b32-23774bd2c095@github.com>
Message-ID: <LGmN3wvMUvN2AbrxPjvxO7Cz1XEqohu3yTnGzlCYIw0=.e73fc551-8bba-4705-bd91-cba2c1c4b478@github.com>

On Fri, 30 Jun 2023 08:11:47 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Most G1 tests set -XX:+UseG1GC, but a few (e.g. gc/g1/TestVerificationInConcurrentCycle.java) miss that.
> This is usually just fine and no problem because G1 is the default anyway.
> However in some cases, where a custom JVM changes the default GC, those tests start to fail which is not really necessary.

Looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14722#pullrequestreview-1506747461

From kevinw at openjdk.org  Fri Jun 30 08:32:24 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 30 Jun 2023 08:32:24 GMT
Subject: RFR: 8310988: Missing @since tags in java.management.rmi
In-Reply-To: <cB2TIYcNzqAJdO4UuK0iglDC2ygeVtWY8PQdqCj9A9A=.83398277-c955-4fc6-8a3f-55eb94d01419@github.com>
References: <cB2TIYcNzqAJdO4UuK0iglDC2ygeVtWY8PQdqCj9A9A=.83398277-c955-4fc6-8a3f-55eb94d01419@github.com>
Message-ID: <oSIPy2fWlD-jgapzQICkuA_KDrN-6Nwi5iG4kj6PHsI=.02eb1e58-48d4-4ea1-9584-c1f86fb6c354@github.com>

On Thu, 29 Jun 2023 16:08:15 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Simple doc tag addition.
> 
> These are files which describe an interface that has been with us since 1.5.  The files themselves were previously generated at build time, but have been in the repo since jdk15.  But the API is since 1.5.
> 
> The other file mentioned in the bug is not a public class and has no javadoc generated, ignoring that one.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/14714#issuecomment-1614310538

From kevinw at openjdk.org  Fri Jun 30 08:32:24 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 30 Jun 2023 08:32:24 GMT
Subject: RFR: 8310988: Missing @since tags in java.management.rmi [v2]
In-Reply-To: <cB2TIYcNzqAJdO4UuK0iglDC2ygeVtWY8PQdqCj9A9A=.83398277-c955-4fc6-8a3f-55eb94d01419@github.com>
References: <cB2TIYcNzqAJdO4UuK0iglDC2ygeVtWY8PQdqCj9A9A=.83398277-c955-4fc6-8a3f-55eb94d01419@github.com>
Message-ID: <qFIdHGCCCfAXQVyrFTQEvm4CiBmP5Uxlc7SrxKF_iks=.9d23615a-79dc-4b60-a70a-487ad53a6349@github.com>

> Simple doc tag addition.
> 
> These are files which describe an interface that has been with us since 1.5.  The files themselves were previously generated at build time, but have been in the repo since jdk15.  But the API is since 1.5.
> 
> The other file mentioned in the bug is not a public class and has no javadoc generated, ignoring that one.

Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:

 - (C)
 - (C)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14714/files
  - new: https://git.openjdk.org/jdk/pull/14714/files/5bc9cc12..634cc78d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14714&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14714&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14714.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14714/head:pull/14714

PR: https://git.openjdk.org/jdk/pull/14714

From kevinw at openjdk.org  Fri Jun 30 08:32:25 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 30 Jun 2023 08:32:25 GMT
Subject: Integrated: 8310988: Missing @since tags in java.management.rmi
In-Reply-To: <cB2TIYcNzqAJdO4UuK0iglDC2ygeVtWY8PQdqCj9A9A=.83398277-c955-4fc6-8a3f-55eb94d01419@github.com>
References: <cB2TIYcNzqAJdO4UuK0iglDC2ygeVtWY8PQdqCj9A9A=.83398277-c955-4fc6-8a3f-55eb94d01419@github.com>
Message-ID: <3YDYDbkf6uPkDDlVgZa7IwRs9lL_AQzunJdcMutZItk=.6c343633-1e9c-4cff-9a6e-14ab5b4bcdf9@github.com>

On Thu, 29 Jun 2023 16:08:15 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Simple doc tag addition.
> 
> These are files which describe an interface that has been with us since 1.5.  The files themselves were previously generated at build time, but have been in the repo since jdk15.  But the API is since 1.5.
> 
> The other file mentioned in the bug is not a public class and has no javadoc generated, ignoring that one.

This pull request has now been integrated.

Changeset: 660cd256
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/660cd256b72154b966208174dbf9abe95c9bfd60
Stats:     6 lines in 2 files changed: 4 ins; 0 del; 2 mod

8310988: Missing @since tags in java.management.rmi

Reviewed-by: rriggs, alanb, jjg, mli

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

PR: https://git.openjdk.org/jdk/pull/14714

From kevinw at openjdk.org  Fri Jun 30 08:33:16 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 30 Jun 2023 08:33:16 GMT
Subject: RFR: 8311000: missing @since info in jdk.management
In-Reply-To: <-f8oRj4ThTKK-rAY9GnVSGlXrPLuIVcuz40dJBaFsF8=.fd87ccc0-858a-4e14-b2a4-d666faf1aa98@github.com>
References: <-f8oRj4ThTKK-rAY9GnVSGlXrPLuIVcuz40dJBaFsF8=.fd87ccc0-858a-4e14-b2a4-d666faf1aa98@github.com>
Message-ID: <2pkOjrEAiB-srGOy0Rpk9gDvexvUPQK2FdVPdjzwMvE=.1b80be8e-0134-4b75-8d64-08b726c738eb@github.com>

On Thu, 29 Jun 2023 11:48:43 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Simple addition of a doc tag.  
> 
> src/share/classes/com/sun/management/GarbageCollectionNotificationInfo.java is introduced in jdk7 by
> 7036199: Adding a notification to the implementation of GarbageCollectorMXBeans

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/14708#issuecomment-1614313233

From kevinw at openjdk.org  Fri Jun 30 08:33:14 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 30 Jun 2023 08:33:14 GMT
Subject: RFR: 8311000: missing @since info in jdk.management [v2]
In-Reply-To: <-f8oRj4ThTKK-rAY9GnVSGlXrPLuIVcuz40dJBaFsF8=.fd87ccc0-858a-4e14-b2a4-d666faf1aa98@github.com>
References: <-f8oRj4ThTKK-rAY9GnVSGlXrPLuIVcuz40dJBaFsF8=.fd87ccc0-858a-4e14-b2a4-d666faf1aa98@github.com>
Message-ID: <8o6HPClQN-coLysy8Ahxm0wl3Rxuwimprqoia-rNr60=.0b166d74-dd7d-4687-be17-8e1a3cde7a8d@github.com>

> Simple addition of a doc tag.  
> 
> src/share/classes/com/sun/management/GarbageCollectionNotificationInfo.java is introduced in jdk7 by
> 7036199: Adding a notification to the implementation of GarbageCollectorMXBeans

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  (C)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14708/files
  - new: https://git.openjdk.org/jdk/pull/14708/files/b4c36af7..30632c98

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14708&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14708&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14708.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14708/head:pull/14708

PR: https://git.openjdk.org/jdk/pull/14708

From kevinw at openjdk.org  Fri Jun 30 08:33:17 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 30 Jun 2023 08:33:17 GMT
Subject: Integrated: 8311000: missing @since info in jdk.management
In-Reply-To: <-f8oRj4ThTKK-rAY9GnVSGlXrPLuIVcuz40dJBaFsF8=.fd87ccc0-858a-4e14-b2a4-d666faf1aa98@github.com>
References: <-f8oRj4ThTKK-rAY9GnVSGlXrPLuIVcuz40dJBaFsF8=.fd87ccc0-858a-4e14-b2a4-d666faf1aa98@github.com>
Message-ID: <O1htjZDvq9cnD41PCBsYzNcf9YaghJG1PbSwnNufP3w=.0327b5c7-0352-4bf2-a614-ffac81015e74@github.com>

On Thu, 29 Jun 2023 11:48:43 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Simple addition of a doc tag.  
> 
> src/share/classes/com/sun/management/GarbageCollectionNotificationInfo.java is introduced in jdk7 by
> 7036199: Adding a notification to the implementation of GarbageCollectorMXBeans

This pull request has now been integrated.

Changeset: c08c9831
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c08c9831df2428e9d083a56eda5ebf00623ba961
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8311000: missing @since info in jdk.management

Reviewed-by: rriggs, mli

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

PR: https://git.openjdk.org/jdk/pull/14708

From kevinw at openjdk.org  Fri Jun 30 08:52:12 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 30 Jun 2023 08:52:12 GMT
Subject: RFR: 8310993: Missing @since tags in jdk.attach
Message-ID: <ZlaGL8Hkom_8l2ypdn5HV_rAhqXmEFQyC6nR391ELPI=.916d1edb-369b-4361-881a-2871f9ee165a@github.com>

Simple since tag addition in selected files.

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

Commit messages:
 - 8310993: Missing @since tags in jdk.attach

Changes: https://git.openjdk.org/jdk/pull/14724/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14724&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310993
  Stats: 11 lines in 4 files changed: 7 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14724.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14724/head:pull/14724

PR: https://git.openjdk.org/jdk/pull/14724

From sspitsyn at openjdk.org  Fri Jun 30 09:22:52 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 30 Jun 2023 09:22:52 GMT
Subject: RFR: 8310993: Missing @since tags in jdk.attach
In-Reply-To: <ZlaGL8Hkom_8l2ypdn5HV_rAhqXmEFQyC6nR391ELPI=.916d1edb-369b-4361-881a-2871f9ee165a@github.com>
References: <ZlaGL8Hkom_8l2ypdn5HV_rAhqXmEFQyC6nR391ELPI=.916d1edb-369b-4361-881a-2871f9ee165a@github.com>
Message-ID: <pWy02lZIN9SHdDQJ-U6HhHn5mgJYVuGdMlvTC5Eoe1k=.621a5c07-fcf7-4f24-a2f2-2683b17a2a07@github.com>

On Fri, 30 Jun 2023 08:44:22 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Simple since tag addition in selected files.

Looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14724#pullrequestreview-1506841290

From mbaesken at openjdk.org  Fri Jun 30 10:02:01 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 30 Jun 2023 10:02:01 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar [v2]
In-Reply-To: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
Message-ID: <Ykg6Amp7406I2u7bTQig2FG2o_g4ebNwgmWCgPOR_Ow=.2394846a-4734-4faf-8d38-77f05d98b95b@github.com>

> There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Adjust comment in src/java.sql/share/classes/java/sql/DriverManager.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14593/files
  - new: https://git.openjdk.org/jdk/pull/14593/files/5d52b4cb..6665f60b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14593&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14593&range=00-01

  Stats: 6 lines in 1 file changed: 1 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14593.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14593/head:pull/14593

PR: https://git.openjdk.org/jdk/pull/14593

From mbaesken at openjdk.org  Fri Jun 30 10:02:03 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 30 Jun 2023 10:02:03 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar [v2]
In-Reply-To: <hduIpeINBeZIgNUPt5qs_TdEG3pTXUdwCxxvIGmpb_k=.6c25d0fc-da5f-4a41-b21d-ce415d6153d0@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
 <CXXV_lxlp7_Ntc0hbwPmVezF5PNqfm3oQpiY4HLl6TE=.a8b48f90-8e50-4022-9280-2e54933289a9@github.com>
 <fZt11UIM3a4eNOSEVvv-KLEYE1pVLbz_hH_ifk9U-18=.e89142c9-ccd1-4ea5-81d5-97f0eb58d54d@github.com>
 <WbcMqs8LKR8wh3khpe0EY_O4A6XEHblMsd9lmqvfUVQ=.a5db7b5c-00f2-4ea2-a5e8-4fcf893739b5@github.com>
 <hduIpeINBeZIgNUPt5qs_TdEG3pTXUdwCxxvIGmpb_k=.6c25d0fc-da5f-4a41-b21d-ce415d6153d0@github.com>
Message-ID: <o1kCrnJzTAiEKF84HDgMZQltwIDLeTBOBXouGC5S_0E=.4087cdc2-b4db-4e35-80ed-72241aee7120@github.com>

On Wed, 28 Jun 2023 13:22:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>>> Hi Alan, regarding usage of class VM I get 'package jdk.internal.misc is declared in module java.base, which does not export it to module java.sql' Is there any concern to export it as well to module java.sql ? And btw did you mean to use it like this, in the if ?
>>> 
>>> `if (callerCL == null || VM.isSystemDomainLoader(callerCL)) { callerCL = Thread.currentThread().getContextClassLoader(); }`
>> 
>> It was just a passing comment, I didn't meant to suggest changing it as part of this PR. We have always think twice before adding qualified exports from java.base and this is case where java.sql is very "non-core", we don't want to give it any access to java.base internals.
>
> Hi Alan, thanks for clarifying.  So I should only adjust the comment, correct ?

Hi Alan, I adjusted the comment in DriverManager.java  .

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14593#discussion_r1247686721

From tschatzl at openjdk.org  Fri Jun 30 11:30:58 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 30 Jun 2023 11:30:58 GMT
Subject: RFR: JDK-8311026: Some G1 specific tests do not set -XX:+UseG1GC
In-Reply-To: <oUHMIq8zmo_V85u0_aClADgteBsHEZCfLhk9rj-KPeU=.64545793-07de-454d-8b32-23774bd2c095@github.com>
References: <oUHMIq8zmo_V85u0_aClADgteBsHEZCfLhk9rj-KPeU=.64545793-07de-454d-8b32-23774bd2c095@github.com>
Message-ID: <9qV2eIvGliad_OWjWBPLTlVRQAItZH7CW4ocxWNiBKY=.c5d60000-9f25-4130-a8f8-7a40a6c57a03@github.com>

On Fri, 30 Jun 2023 08:11:47 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Most G1 tests set -XX:+UseG1GC, but a few (e.g. gc/g1/TestVerificationInConcurrentCycle.java) miss that.
> This is usually just fine and no problem because G1 is the default anyway.
> However in some cases, where a custom JVM changes the default GC, those tests start to fail which is not really necessary.

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14722#pullrequestreview-1507020443

From sspitsyn at openjdk.org  Fri Jun 30 11:33:55 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 30 Jun 2023 11:33:55 GMT
Subject: RFR: 8303086: SIGSEGV in JavaThread::is_interp_only_mode()
Message-ID: <5PhlR3J_Cg-n5DSnX258xNjol34M6eqgTd3AZaoDNsc=.4c7d9382-9f5d-4bdd-b985-7ffc4149da67@github.com>

The JVMTI function `SetEventNotificationMode` can set notification mode globally (`event_thread == nullptr`) for all threads or for a specific thread (`event_thread != nullptr`). To get a stable mount/unmount vision of virtual threads a JvmtiVTMSTransitionDisabler helper object is created :
    `JvmtiVTMSTransitionDisabler disabler(event_thread);`

In a case if `event_thread == nullptr` the VTMS transitions are disabled for all virtual thread,
otherwise they are disabled for a specific thread if it is virtual.
The call to `JvmtiEventController::set_user_enabled()` makes a call to `recompute_enabled()` at the end of its work to do a required bookkeeping. As part of this work, the `recompute_thread_enabled(state)` is called for each thread from the `ThreadsListHandle`, not only for the given specific `event_thread`.
This can cause crashes as VTMS transitions for other virtual threads are allowed.
Crashes are observed in this small function:

  bool is_interp_only_mode() {
    return _thread == nullptr ? _saved_interp_only_mode != 0 : _thread->is_interp_only_mode();
  }

In a case `_thread != nullptr` then the call needs to be executed: `_thread->is_interp_only_mode()`.
But the filed `_thread` can be already changed to `nullptr` by a VTMS transition.

The fix is to always disable all transitions.
Thanks to Dan and Patricio for great analysis of this crash!

Testing:
- In progress: mach5 tiers 1-6

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

Commit messages:
 - 8303086: SIGSEGV in JavaThread::is_interp_only_mode()

Changes: https://git.openjdk.org/jdk/pull/14728/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14728&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303086
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14728/head:pull/14728

PR: https://git.openjdk.org/jdk/pull/14728

From mbaesken at openjdk.org  Fri Jun 30 11:37:10 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 30 Jun 2023 11:37:10 GMT
Subject: RFR: JDK-8310550: Adjust references to rt.jar [v3]
In-Reply-To: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
References: <qXU1oR8gwPKjO6f2eZOThnj3cheJWr1j_laDc62HcZg=.39e726fb-9a5f-4573-9183-56efafc9c5d7@github.com>
Message-ID: <hz2VoLHbP2n0_RAq1krcyEIlrHwRN0yHdeX5MCKylMg=.b35456f5-6ee6-4007-a575-4ddd8ea7f465@github.com>

> There are a few references to rt.jar in comments and in the codebase itself. Some of them might be removed or adjusted.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  remove import

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14593/files
  - new: https://git.openjdk.org/jdk/pull/14593/files/6665f60b..9b2232a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14593&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14593&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14593.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14593/head:pull/14593

PR: https://git.openjdk.org/jdk/pull/14593

From mbaesken at openjdk.org  Fri Jun 30 11:38:06 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 30 Jun 2023 11:38:06 GMT
Subject: RFR: JDK-8311026: Some G1 specific tests do not set -XX:+UseG1GC
In-Reply-To: <oUHMIq8zmo_V85u0_aClADgteBsHEZCfLhk9rj-KPeU=.64545793-07de-454d-8b32-23774bd2c095@github.com>
References: <oUHMIq8zmo_V85u0_aClADgteBsHEZCfLhk9rj-KPeU=.64545793-07de-454d-8b32-23774bd2c095@github.com>
Message-ID: <DNdVwxC4sLBdysLVmCB1qX4tpWS3RaZAOAP8wki5Imk=.da3eaecf-2ddb-439b-928a-0f2076caa9af@github.com>

On Fri, 30 Jun 2023 08:11:47 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Most G1 tests set -XX:+UseG1GC, but a few (e.g. gc/g1/TestVerificationInConcurrentCycle.java) miss that.
> This is usually just fine and no problem because G1 is the default anyway.
> However in some cases, where a custom JVM changes the default GC, those tests start to fail which is not really necessary.

Hi Thomas and Serguei, thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/14722#issuecomment-1614525324

From mbaesken at openjdk.org  Fri Jun 30 11:38:06 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 30 Jun 2023 11:38:06 GMT
Subject: Integrated: JDK-8311026: Some G1 specific tests do not set
 -XX:+UseG1GC
In-Reply-To: <oUHMIq8zmo_V85u0_aClADgteBsHEZCfLhk9rj-KPeU=.64545793-07de-454d-8b32-23774bd2c095@github.com>
References: <oUHMIq8zmo_V85u0_aClADgteBsHEZCfLhk9rj-KPeU=.64545793-07de-454d-8b32-23774bd2c095@github.com>
Message-ID: <QSDcoza58IO1fabVgd7FPockuvk3EdR7Zie6h81ec1s=.cc8cc36f-d10e-4b88-bd1f-6c3f6c66e704@github.com>

On Fri, 30 Jun 2023 08:11:47 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Most G1 tests set -XX:+UseG1GC, but a few (e.g. gc/g1/TestVerificationInConcurrentCycle.java) miss that.
> This is usually just fine and no problem because G1 is the default anyway.
> However in some cases, where a custom JVM changes the default GC, those tests start to fail which is not really necessary.

This pull request has now been integrated.

Changeset: a7d168b5
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a7d168b522bb05345a40ae1fb18942ba663d3182
Stats:     4 lines in 3 files changed: 0 ins; 0 del; 4 mod

8311026: Some G1 specific tests do not set -XX:+UseG1GC

Reviewed-by: sspitsyn, tschatzl

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

PR: https://git.openjdk.org/jdk/pull/14722

From mbaesken at openjdk.org  Fri Jun 30 12:42:53 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 30 Jun 2023 12:42:53 GMT
Subject: [jdk21] RFR: 8310380: Handle problems in core-related tests on macOS
 when codesign tool does not work
Message-ID: <lIBG-SnwaigKmGPTr0olt-v0RWKnirL-TA5yubgu2BM=.6075f4e2-6f9a-4fc8-8d42-d41fb9d9602f@github.com>

8310380: Handle problems in core-related tests on macOS when codesign tool does not work

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

Commit messages:
 - Backport 39c104df44f17c1d65e35becd4272f73e2c6610c

Changes: https://git.openjdk.org/jdk21/pull/87/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=87&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310380
  Stats: 56 lines in 4 files changed: 37 ins; 12 del; 7 mod
  Patch: https://git.openjdk.org/jdk21/pull/87.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/87/head:pull/87

PR: https://git.openjdk.org/jdk21/pull/87

From coleenp at openjdk.org  Fri Jun 30 13:10:06 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 30 Jun 2023 13:10:06 GMT
Subject: RFR: 8311077: Fix -Wconversion warnings in jvmti code [v4]
In-Reply-To: <01jxrp1E-_5hGZ91QI0Og2XgbksXszXHWSzRiiuX9OM=.8d132e37-3821-4b48-a8e4-c3f2efb7b3ea@github.com>
References: <01jxrp1E-_5hGZ91QI0Og2XgbksXszXHWSzRiiuX9OM=.8d132e37-3821-4b48-a8e4-c3f2efb7b3ea@github.com>
Message-ID: <beA1d_-c3nE54oicAp_ZxN_lQUvvMfyiaSyPZ_pvSvw=.8069f8bb-d3ed-437b-99d6-28e43297c477@github.com>

> Please review change for mostly fixing return types in the constant pool and metadata to fix -Wconversion warnings in JVMTI code.  The order of preference for changes are: 1. change the types to more distinct types (fields in the constant pool are u2 because that's their size in the classfile), 2. add direct int casts if the value has been checked in asserts above, and 3. checked_cast<> if not verified, and 4. added some pointer_delta_as_ints where needed.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  David's suggestions.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14710/files
  - new: https://git.openjdk.org/jdk/pull/14710/files/42781421..d07a212c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14710&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14710&range=02-03

  Stats: 6 lines in 4 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/14710.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14710/head:pull/14710

PR: https://git.openjdk.org/jdk/pull/14710

From coleenp at openjdk.org  Fri Jun 30 13:10:07 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 30 Jun 2023 13:10:07 GMT
Subject: RFR: 8311077: Fix -Wconversion warnings in jvmti code [v3]
In-Reply-To: <mx5tJLlrj-p4MYD_519hWTOxKarSwS6zdgamH1UbLGc=.39a7e632-c1b6-4fec-8ddf-25d44fd5999f@github.com>
References: <01jxrp1E-_5hGZ91QI0Og2XgbksXszXHWSzRiiuX9OM=.8d132e37-3821-4b48-a8e4-c3f2efb7b3ea@github.com>
 <mx5tJLlrj-p4MYD_519hWTOxKarSwS6zdgamH1UbLGc=.39a7e632-c1b6-4fec-8ddf-25d44fd5999f@github.com>
Message-ID: <WyA4y1dpXQOfiAXbTauvo7MpL-jusJEgTAZMHSP5Z-o=.0db1c9f5-9b43-4e60-973e-51d4bbe2ab2e@github.com>

On Thu, 29 Jun 2023 17:29:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review change for mostly fixing return types in the constant pool and metadata to fix -Wconversion warnings in JVMTI code.  The order of preference for changes are: 1. change the types to more distinct types (fields in the constant pool are u2 because that's their size in the classfile), 2. add direct int casts if the value has been checked in asserts above, and 3. checked_cast<> if not verified, and 4. added some pointer_delta_as_ints where needed.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a comment about u1 cast to new_index for the ldc bytecode.

The task is NOT to just silence the conversion warnings but to correct the types to be more precise to not get conversion warnings.  That's what this change does. I think I've answered your questions about the types chosen.

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

PR Review: https://git.openjdk.org/jdk/pull/14710#pullrequestreview-1507060957

From coleenp at openjdk.org  Fri Jun 30 13:10:18 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 30 Jun 2023 13:10:18 GMT
Subject: RFR: 8311077: Fix -Wconversion warnings in jvmti code [v3]
In-Reply-To: <wl6xt8GqBTcLHud-BstO5uw2EfbKNpwtqWRv-aYVJu0=.318f70a0-c88e-43ad-ade4-35148e9c7715@github.com>
References: <01jxrp1E-_5hGZ91QI0Og2XgbksXszXHWSzRiiuX9OM=.8d132e37-3821-4b48-a8e4-c3f2efb7b3ea@github.com>
 <mx5tJLlrj-p4MYD_519hWTOxKarSwS6zdgamH1UbLGc=.39a7e632-c1b6-4fec-8ddf-25d44fd5999f@github.com>
 <wl6xt8GqBTcLHud-BstO5uw2EfbKNpwtqWRv-aYVJu0=.318f70a0-c88e-43ad-ade4-35148e9c7715@github.com>
Message-ID: <YsUpq7Ts23JghauG25wkPILQ1fYBffRUKqegRqBO3zc=.3e572b24-f72f-4690-b8a6-e88d3b6cfdac@github.com>

On Fri, 30 Jun 2023 01:52:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add a comment about u1 cast to new_index for the ldc bytecode.
>
> src/hotspot/share/oops/constMethod.hpp line 327:
> 
>> 325: 
>> 326:   // code size
>> 327:   u2 code_size() const                          { return _code_size; }
> 
> The `code_length` of a `Code` attribute is `u4` - why is `u2` appropriate here?

The code_length attribute is defined in the class file specification as u4, but further specifies that:

code_length
The value of the code_length item gives the number of bytes in the code array for this method.

The value of code_length must be greater than zero (as the code array must not be empty) and less than 65536.


So we store code_length as a u2 to save space in the ConstMethod.  That's the size of the field _code_size.  There are checks in set_code_size and in the ClassFileParser to verify this:


        guarantee_property(code_length > 0 && code_length <= MAX_CODE_SIZE,
                           "Invalid method Code length %u in class file %s",
                           code_length, CHECK_NULL);


And further when assigning code_size:


  void set_code_size(int size) {
    assert(max_method_code_size < (1 << 16),
           "u2 is too small to hold method code size in general");
    assert(0 <= size && size <= max_method_code_size, "invalid code size");
    _code_size = (u2)size;
  }   


At one point, there was discussion of expanding the code_size to u4.  If that decision is made, we should change these types.  I made the return type match the field type because it's copied when we create a new method.  I did that to avoid a cast.

> src/hotspot/share/oops/method.hpp line 257:
> 
>> 255: 
>> 256:   // code size
>> 257:   u2 code_size() const                   { return constMethod()->code_size(); }
> 
> Again why is this not u4?

see above.

> src/hotspot/share/oops/method.hpp line 269:
> 
>> 267:   // return original max stack size for method verification
>> 268:   u2  verifier_max_stack() const               { return constMethod()->max_stack(); }
>> 269:   int          max_stack() const               { return constMethod()->max_stack() + extra_stack_entries(); }
> 
> So this has to be greater than a `u2` because of the extra entries?

Yes.

> src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp line 310:
> 
>> 308:   write_attribute_name_index("MethodParameters");
>> 309:   write_u4(size);
>> 310:   write_u1((u1)length);
> 
> What is the rule for using a plain cast versus a checked_cast?

If the code above explicitly checks for the value of the int, then I don't use checked_cast<>.  The explicit checks are more descriptive of the expectations and that assert would be better than the checked_cast<> assert which is somewhat generic.

> src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp line 402:
> 
>> 400:     length += sizeof(u2); // bootstrap_method_ref
>> 401:     length += sizeof(u2); // num_bootstrap_arguments
>> 402:     length += (int)sizeof(u2) * num_bootstrap_arguments; // bootstrap_arguments[num_bootstrap_arguments]
> 
> Not clear why the int cast is used given length is a u4?

I could change that to u4.  It's the same thing.  It just can't be size_t.  I really don't know why the C++ compiler gives this a Wconversion warning and not the lines above it.


src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp:402:12: warning: conversion from 'long unsigned int' to 'u4' {aka 'unsigned int'} may change value [-Wconversion]
  402 |     length += sizeof(u2) * num_bootstrap_arguments; // bootstrap_arguments[num_bootstrap_arguments]
      |     ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

> src/hotspot/share/prims/jvmtiRawMonitor.cpp line 83:
> 
>> 81: bool
>> 82: JvmtiRawMonitor::is_valid() {
>> 83:   uint64_t value = 0;
> 
> Why `uint64_t` here when `JvmtiEnvBase::is_valid` uses `jlong`?

It's the same type.  Since we're not already using a jlong in this function, I used the preferable uint64_t.  I can make it jlong if you prefer that.

> src/hotspot/share/prims/jvmtiRawMonitor.cpp line 385:
> 
>> 383:   OrderAccess::fence();
>> 384: 
>> 385:   int save = _recursions;
> 
> `_recursions` is `intx`

JvmtiRawMonitor _recursions is an int.  Maybe it shouldn't be.  You could file an RFE to change that if it's wrong.


  volatile int _recursions;     // recursion count, 0 for first entry

> src/hotspot/share/prims/jvmtiTrace.cpp line 205:
> 
>> 203:               _trace_flags[i] |= bits;
>> 204:             } else {
>> 205:               _trace_flags[i] &= (jbyte)~bits;
> 
> Looks strange that only this use of bits needs the cast?

Yes the ~ operator promotes to int. 

https://en.cppreference.com/w/cpp/language/operator_arithmetic


Conversions
If the operand passed to an arithmetic operator is integral or unscoped enumeration type, then before any other action (but after lvalue-to-rvalue conversion, if applicable), the operand undergoes [integral promotion](https://en.cppreference.com/w/cpp/language/implicit_conversion#Integral_promotion). If an operand has array or function type, [array-to-pointer](https://en.cppreference.com/w/cpp/language/implicit_conversion#array_to_pointer_conversion) and [function-to-pointer](https://en.cppreference.com/w/cpp/language/implicit_conversion#function_to_pointer) conversions are applied.

For the binary operators (except shifts), if the promoted operands have different types, [usual arithmetic conversions](https://en.cppreference.com/w/cpp/language/usual_arithmetic_conversions) are applied.



char, signed char, unsigned char, short and unsigned short can be converted to int if their respective entire value range can be held by the type int, or unsigned int otherwise;

> src/hotspot/share/prims/jvmtiTrace.cpp line 234:
> 
>> 232:             _event_trace_flags[i] |= bits;
>> 233:           } else {
>> 234:             _event_trace_flags[i] &= (jbyte)~bits;
> 
> Looks strange that only this use of bits needs the cast?

Same - the ~ operator promotes to int.

> src/hotspot/share/runtime/jfieldIDWorkaround.hpp line 87:
> 
>> 85:     return ((as_uint & checked_mask_in_place) != 0);
>> 86:   }
>> 87:   static int raw_instance_offset(jfieldID id) {
> 
> This doesn't look right as we've gone from returning a 64-bit value to a 32-bit value. If it is meant to be only 32-bit I expect the callers need some adjustment too.

static jfieldID to_instance_jfieldID(Klass* k, int offset) {

We encode the offset as an int so to get the offset back again, it should be an int.

I worked out the calculation once but I could just check_cast<int> the 1 jvmti caller instead, and save the 7 jni callers for another pass.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14710#discussion_r1247783660
PR Review Comment: https://git.openjdk.org/jdk/pull/14710#discussion_r1247833600
PR Review Comment: https://git.openjdk.org/jdk/pull/14710#discussion_r1247784556
PR Review Comment: https://git.openjdk.org/jdk/pull/14710#discussion_r1247833066
PR Review Comment: https://git.openjdk.org/jdk/pull/14710#discussion_r1247784903
PR Review Comment: https://git.openjdk.org/jdk/pull/14710#discussion_r1247825020
PR Review Comment: https://git.openjdk.org/jdk/pull/14710#discussion_r1247826857
PR Review Comment: https://git.openjdk.org/jdk/pull/14710#discussion_r1247788982
PR Review Comment: https://git.openjdk.org/jdk/pull/14710#discussion_r1247793928
PR Review Comment: https://git.openjdk.org/jdk/pull/14710#discussion_r1247802771

From coleenp at openjdk.org  Fri Jun 30 13:10:19 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 30 Jun 2023 13:10:19 GMT
Subject: RFR: 8311077: Fix -Wconversion warnings in jvmti code [v4]
In-Reply-To: <1838l9S8X7CSCeDdkqjsEUPSW1A8dgKD3xjXmqmdQPg=.5756c1a3-8590-451e-a565-62b1cd1dc34e@github.com>
References: <01jxrp1E-_5hGZ91QI0Og2XgbksXszXHWSzRiiuX9OM=.8d132e37-3821-4b48-a8e4-c3f2efb7b3ea@github.com>
 <mx5tJLlrj-p4MYD_519hWTOxKarSwS6zdgamH1UbLGc=.39a7e632-c1b6-4fec-8ddf-25d44fd5999f@github.com>
 <AODogPLCAAAChm1r4MTmDgqJw5Sd5iPsKZhSBVljBWU=.edc16278-06db-462a-875f-9be87d167c82@github.com>
 <yZTvD0jWS2D6MQ2K5-GuuVz7QbmPMoe7S0DE8KqV8b0=.a37a1ebe-2344-4238-a7b5-05141d9ef2d3@github.com>
 <1838l9S8X7CSCeDdkqjsEUPSW1A8dgKD3xjXmqmdQPg=.5756c1a3-8590-451e-a565-62b1cd1dc34e@github.com>
Message-ID: <7tKE46sCwnTiAknIsgcDpaEqbxL4GH970MnNEjaIHow=.35e62728-1141-491b-bc89-96445e41b8ba@github.com>

On Fri, 30 Jun 2023 02:11:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I had to change these two lines because BytecodeStream::get_index_u2 returns an int, so got the warning and this didn't need to be declared with u2.  get_index_u2() could be fixed to return a u2 but I didn't want to go that far as no casts were involved in this change.
>
> I think this change looks "wrong" - the indices are supposed to be u2's, if the function returns an int that seems an error.

Fixing these functions will have fallout further down in the code, so I didn't want to do this.  These functions are used in a lot of places in the code where int is used for convenience.  int is a convenient type.  This didn't require a cast because the function klass_at_noresolve()'s parameter is an int.  This isn't wrong.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14710#discussion_r1247802199

From coleenp at openjdk.org  Fri Jun 30 13:17:00 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 30 Jun 2023 13:17:00 GMT
Subject: RFR: 8311077: Fix -Wconversion warnings in jvmti code [v3]
In-Reply-To: <wl6xt8GqBTcLHud-BstO5uw2EfbKNpwtqWRv-aYVJu0=.318f70a0-c88e-43ad-ade4-35148e9c7715@github.com>
References: <01jxrp1E-_5hGZ91QI0Og2XgbksXszXHWSzRiiuX9OM=.8d132e37-3821-4b48-a8e4-c3f2efb7b3ea@github.com>
 <mx5tJLlrj-p4MYD_519hWTOxKarSwS6zdgamH1UbLGc=.39a7e632-c1b6-4fec-8ddf-25d44fd5999f@github.com>
 <wl6xt8GqBTcLHud-BstO5uw2EfbKNpwtqWRv-aYVJu0=.318f70a0-c88e-43ad-ade4-35148e9c7715@github.com>
Message-ID: <_nBpLsodYhYoe-4QMbRhtMoGEhKvbGxx6LDFG63fD7A=.dfd1e392-566c-40d9-b386-0aac39692a4f@github.com>

On Fri, 30 Jun 2023 02:18:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add a comment about u1 cast to new_index for the ldc bytecode.
>
> Sorry Coleen but this raises a lot of questions for me. I expect there are a few ways to silence these conversion warnings but many of the proposed changes don't look semantically right to me. I realize that we have a lot of inconsistencies in the way we declare and use types and that the proposed changes may be the most minimal way to fix things, but it is better to type them correctly from the start IMO and only cast at the "boundaries" if it requires a change to propagate too far.

@dholmes-ora The reason that these changes are broken up like this is because there are a huge amount of -Wconversion warnings and to do it right, we need to examine where the warnings are to see if there are bugs, and to correct the code to either use the right types or allow the cast with an assertion check if necessary.  The changes are not designed to be completely minimal but balanced so that people can review them and that changes that aren't necessary aren't made.
We pass around 'int' as a parameter type for values that are u2, for example.  It really matters most when we're storing that value or using it in a context that requires the narrow type.  If we're using it as an index which most constant pool and constant pool cache indices are used as, we can keep it as an int.  A u2 parameter is promoted to int so it's the same thing.
I hope I've answered your questions about these specific types in this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/14710#issuecomment-1614635744

From djelinski at openjdk.org  Fri Jun 30 14:31:54 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 30 Jun 2023 14:31:54 GMT
Subject: RFR: 8310948: Fix ignored-qualifiers warning in Hotspot
In-Reply-To: <hNI7tUjnrrsVnOlgJUzzLywNXljokcIjUBuH3DgtHdE=.f26e72bb-591f-48f1-8dfe-f4c85254b72f@github.com>
References: <hNI7tUjnrrsVnOlgJUzzLywNXljokcIjUBuH3DgtHdE=.f26e72bb-591f-48f1-8dfe-f4c85254b72f@github.com>
Message-ID: <MM7P4dViyFokzuGnm8t7YhywSW2w6gWT7LnjNPWYHI4=.88dc1236-9ad5-439e-8585-adea24b7a6f8@github.com>

On Tue, 27 Jun 2023 12:22:43 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this attempt to fix ignored-qualifiers warning.
> 
> Example warnings:
> 
> src/hotspot/share/oops/method.hpp:413:19: warning: 'volatile' type qualifier on return type has no effect [-Wignored-qualifiers]
>    CompiledMethod* volatile code() const;
>                    ^~~~~~~~~
> 
> 
> src/hotspot/share/jfr/periodic/jfrModuleEvent.cpp:65:20: warning: type qualifiers ignored on cast result type [-Wignored-qualifiers]
>     65 |   event.set_source((const ModuleEntry* const)from_module);
>        |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> 
> The proposed fix removes the ignored qualifiers.
> In a few AD files I replaced `const` with `constexpr` where I noticed that the method is returning a compile-time constant, and other platforms use `constexpr` on the same method.
> 
> Release, debug and slowdebug builds on Aarch64 / x64 and Mac / Linux complete without errors. Cross-compile GHA builds also pass.

Can I get another +1 on this? or should I proceed with splitting?

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

PR Comment: https://git.openjdk.org/jdk/pull/14674#issuecomment-1614738114

From dnsimon at openjdk.org  Fri Jun 30 14:40:06 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 30 Jun 2023 14:40:06 GMT
Subject: RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit [v7]
In-Reply-To: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
References: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
Message-ID: <nR63VC3xYw5iAF0C4Mi1WGhrEClEfP88d4Hohr8M5qE=.8ee05c4d-10dd-4def-acb5-c3730e7a622a@github.com>

> The VMSupport class is required for translating an exception between the HotSpot and libgraal heaps.
> Loading it lazily can result in a loading exception, obscuring the exception being translated.
> To avoid this, VMSupport is loaded eagerly along with the other vmClasses.

Doug Simon has updated the pull request incrementally with one additional commit since the last revision:

  fix warning about conversion from size_t to int

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14641/files
  - new: https://git.openjdk.org/jdk/pull/14641/files/e46a6a17..5bb3b529

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14641&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14641&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14641.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14641/head:pull/14641

PR: https://git.openjdk.org/jdk/pull/14641

From dnsimon at openjdk.org  Fri Jun 30 14:40:09 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 30 Jun 2023 14:40:09 GMT
Subject: RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit [v6]
In-Reply-To: <PAmaIcD3QoUOkp-XmZG2uhkLgvyJs8altN90PoW4pB4=.37f7fa52-fc02-48b7-9cae-0ed3edc23ed4@github.com>
References: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
 <PAmaIcD3QoUOkp-XmZG2uhkLgvyJs8altN90PoW4pB4=.37f7fa52-fc02-48b7-9cae-0ed3edc23ed4@github.com>
Message-ID: <aYRByhmHK3vixOoiNa27btl3VASNg0zPeRNmPXFOGnA=.fe1447ee-ba38-44ef-b34b-4f3b2a57aa72@github.com>

On Thu, 29 Jun 2023 20:06:19 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> The VMSupport class is required for translating an exception between the HotSpot and libgraal heaps.
>> Loading it lazily can result in a loading exception, obscuring the exception being translated.
>> To avoid this, VMSupport is loaded eagerly along with the other vmClasses.
>
> Doug Simon 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:
> 
>  - [skip ci] Merge remote-tracking branch 'openjdk-jdk/master' into JDK-8310829
>  - [skip ci] handle pending HotSpot exception closer to site causing exception
>  - revert to lazy loading of VMSupport
>  - each exception translation failure should trigger a JVMCI event
>  - try harder to show nested exception during exception translation
>  - resolve VMSupport at bootstrap to avoid nested exception in ExceptionTranslation::doit

I have fixed the warning on Windows: 5bb3b529d36c906ac861e5ebf1b861dbb35bfe2c

> But, please, activate GHA testing for this branch.

Isn't GHA a strict subset of or equal to tier1 mach5 testing? If so, what's the point of doing redundant testing?

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

PR Comment: https://git.openjdk.org/jdk/pull/14641#issuecomment-1614746764

From duke at openjdk.org  Fri Jun 30 14:40:26 2023
From: duke at openjdk.org (Ashutosh Mehra)
Date: Fri, 30 Jun 2023 14:40:26 GMT
Subject: RFR: 8311102: Write annotations in the classfile dumped by SA
Message-ID: <bvzObppvdVSvHJHH4xfB_A5M6ZJRyXMF-YzCiAbkL6w=.be64a402-949a-4790-a975-8d37cf4496b7@github.com>

Please review this PR that enables ClassWriter to write annotations to the class file being dumped.

The fields annotations are stored in `Annotations::_fields_annotations` which is of type `Array<Array<u1>*>`. There is no class in SA that can represent it. I have added ArrayOfU1Array to correspond to the type `Array<Array<u1>*>` and it works. I believe there are better approaches but that would require a bit more refactoring of the classes representing Array types. I will leave that for future work for now.

Testing: `test/hotspot/jtreg/serviceability/sa` and `test/jdk/sun/tools/jhsdb`
Tested it manually by dumping j.l.String class and comparing the annotations with the original class using javap.
The test case mentioned in [JDK-8311101](https://bugs.openjdk.org/browse/JDK-8311101) would provide better coverage.

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

Commit messages:
 - 8311102: Write annotations in the classfile dumped by SA

Changes: https://git.openjdk.org/jdk/pull/14735/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14735&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311102
  Stats: 379 lines in 9 files changed: 376 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14735.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14735/head:pull/14735

PR: https://git.openjdk.org/jdk/pull/14735

From dnsimon at openjdk.org  Fri Jun 30 15:15:16 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 30 Jun 2023 15:15:16 GMT
Subject: RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit [v8]
In-Reply-To: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
References: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
Message-ID: <rD22LkfROcqA7CHJQ87-YqakGn1UrcfHLrZstlEpTro=.74d29a90-b6b8-410b-a7e9-bd89fcb10967@github.com>

> The VMSupport class is required for translating an exception between the HotSpot and libgraal heaps.
> Loading it lazily can result in a loading exception, obscuring the exception being translated.
> To avoid this, VMSupport is loaded eagerly along with the other vmClasses.

Doug Simon has updated the pull request incrementally with one additional commit since the last revision:

  fix warning about conversion from size_t to int - take 2

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14641/files
  - new: https://git.openjdk.org/jdk/pull/14641/files/5bb3b529..11a2dad5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14641&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14641&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14641.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14641/head:pull/14641

PR: https://git.openjdk.org/jdk/pull/14641

From dcubed at openjdk.org  Fri Jun 30 15:21:10 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 30 Jun 2023 15:21:10 GMT
Subject: RFR: 8311043: Remove trailing blank lines in source files
In-Reply-To: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
References: <x57rGoMtwsrK6gA4FSHY3S_wB0XJcamNgI6h2HRF9lc=.aa540e9c-89ef-4157-9f8e-1282df0de9d0@github.com>
Message-ID: <1HPsLLkrre-aTNkUCrJ2Os1Ba20NZW-s3bYL1nJU17Q=.47ea0d5b-f382-48a5-ba1b-957a003277d6@github.com>

On Wed, 28 Jun 2023 16:54:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Remove trailing "blank" lines in source files.
> 
> I like to use global-whitespace-cleanup-mode, but I can not use it if the files are "dirty" to begin with. This fix will make more files "clean". I also considered adding a check for this in jcheck for Skara, however it seems jcheck code handling hunks does not track end-of-files. Thus I will only clean the files.
> 
> The fix removes trailing lines matching ^[[:space:]]*$ in
> 
> - *.java
> - *.cpp
> - *.hpp
> - *.c
> - *.h 
> 
> I have applied the following bash script to each file:
> 
>     file="$1"
>     
>     while [[ $(tail -n 1 "$file") =~ ^[[:space:]]*$ ]]; do
>         truncate -s -1 "$file"
>     done
> 
> `git diff --ignore-space-change --ignore-blank-lines  master` displays no changes
> `git diff --ignore-blank-lines  master` displays one change

Ending the file with a blank line? I would not have expected that at all.
I expect a single EOL at the end of the file; from a visual POV, the last
line of non-blank text ends with an EOL. No more, no less.

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

PR Comment: https://git.openjdk.org/jdk/pull/14698#issuecomment-1614806396

From pchilanomate at openjdk.org  Fri Jun 30 15:24:53 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 30 Jun 2023 15:24:53 GMT
Subject: RFR: 8303086: SIGSEGV in JavaThread::is_interp_only_mode()
In-Reply-To: <5PhlR3J_Cg-n5DSnX258xNjol34M6eqgTd3AZaoDNsc=.4c7d9382-9f5d-4bdd-b985-7ffc4149da67@github.com>
References: <5PhlR3J_Cg-n5DSnX258xNjol34M6eqgTd3AZaoDNsc=.4c7d9382-9f5d-4bdd-b985-7ffc4149da67@github.com>
Message-ID: <ruP9nDQ768hCbpGwrux4ugj9rPn7CHCQZakWB4HKATg=.811024b1-25c5-4064-a470-bc0c5778ec4d@github.com>

On Fri, 30 Jun 2023 11:27:58 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The JVMTI function `SetEventNotificationMode` can set notification mode globally (`event_thread == nullptr`) for all threads or for a specific thread (`event_thread != nullptr`). To get a stable mount/unmount vision of virtual threads a JvmtiVTMSTransitionDisabler helper object is created :
>     `JvmtiVTMSTransitionDisabler disabler(event_thread);`
> 
> In a case if `event_thread == nullptr` the VTMS transitions are disabled for all virtual thread,
> otherwise they are disabled for a specific thread if it is virtual.
> The call to `JvmtiEventController::set_user_enabled()` makes a call to `recompute_enabled()` at the end of its work to do a required bookkeeping. As part of this work, the `recompute_thread_enabled(state)` is called for each thread from the `ThreadsListHandle`, not only for the given `event_thread`:
> 
>     ThreadsListHandle tlh;
>     for (; state != nullptr; state = state->next()) {
>       any_env_thread_enabled |= recompute_thread_enabled(state);
>     }
> 
> This can cause crashes as VTMS transitions for other virtual threads are allowed.
> Crashes are observed in this small function:
> 
>   bool is_interp_only_mode() {
>     return _thread == nullptr ? _saved_interp_only_mode != 0 : _thread->is_interp_only_mode();
>   }
> 
> In a case `_thread != nullptr` then the call needs to be executed: `_thread->is_interp_only_mode()`.
> But the filed `_thread` can be already changed to `nullptr` by a VTMS transition.
> 
> The fix is to always disable all transitions.
> Thanks to Dan and Patricio for great analysis of this crash!
> 
> Testing:
> - In progress: mach5 tiers 1-6

Looks good to me!

Patricio

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

Marked as reviewed by pchilanomate (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14728#pullrequestreview-1507404209

From kvn at openjdk.org  Fri Jun 30 17:33:56 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 30 Jun 2023 17:33:56 GMT
Subject: RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit [v8]
In-Reply-To: <rD22LkfROcqA7CHJQ87-YqakGn1UrcfHLrZstlEpTro=.74d29a90-b6b8-410b-a7e9-bd89fcb10967@github.com>
References: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
 <rD22LkfROcqA7CHJQ87-YqakGn1UrcfHLrZstlEpTro=.74d29a90-b6b8-410b-a7e9-bd89fcb10967@github.com>
Message-ID: <H2zr84kViBonB1gaByEwRAiznha8kDweLg3ZaBzvw8k=.79fc0b0f-ac17-4047-bb22-724f0ae6f0a9@github.com>

On Fri, 30 Jun 2023 15:15:16 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> The VMSupport class is required for translating an exception between the HotSpot and libgraal heaps.
>> Loading it lazily can result in a loading exception, obscuring the exception being translated.
>> To avoid this, VMSupport is loaded eagerly along with the other vmClasses.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix warning about conversion from size_t to int - take 2

Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14641#pullrequestreview-1507604563

From kvn at openjdk.org  Fri Jun 30 17:33:57 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 30 Jun 2023 17:33:57 GMT
Subject: RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit [v6]
In-Reply-To: <aYRByhmHK3vixOoiNa27btl3VASNg0zPeRNmPXFOGnA=.fe1447ee-ba38-44ef-b34b-4f3b2a57aa72@github.com>
References: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
 <PAmaIcD3QoUOkp-XmZG2uhkLgvyJs8altN90PoW4pB4=.37f7fa52-fc02-48b7-9cae-0ed3edc23ed4@github.com>
 <aYRByhmHK3vixOoiNa27btl3VASNg0zPeRNmPXFOGnA=.fe1447ee-ba38-44ef-b34b-4f3b2a57aa72@github.com>
Message-ID: <NCCifJKoLoCh0HAXDmEbQhUb2r6LfkfNjy4DfoyHpiw=.c3802651-1189-4a78-b8de-e1d3f01b6ad8@github.com>

On Fri, 30 Jun 2023 14:35:10 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> > But, please, activate GHA testing for this branch.
> 
> Isn't GHA a strict subset of or equal to tier1 mach5 testing? If so, what's the point of doing redundant testing?

It builds and tests configurations (32-bit) we don't have in our testing.

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

PR Comment: https://git.openjdk.org/jdk/pull/14641#issuecomment-1614962751

From cjplummer at openjdk.org  Fri Jun 30 17:44:54 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 30 Jun 2023 17:44:54 GMT
Subject: RFR: 8310993: Missing @since tags in jdk.attach
In-Reply-To: <ZlaGL8Hkom_8l2ypdn5HV_rAhqXmEFQyC6nR391ELPI=.916d1edb-369b-4361-881a-2871f9ee165a@github.com>
References: <ZlaGL8Hkom_8l2ypdn5HV_rAhqXmEFQyC6nR391ELPI=.916d1edb-369b-4361-881a-2871f9ee165a@github.com>
Message-ID: <6YdpsJJGZXNTQ3bjqAHfMMt07MjGO4bdSrgYPhjwoeQ=.260f2880-c35f-43dd-8081-2891cb05cb36@github.com>

On Fri, 30 Jun 2023 08:44:22 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Simple since tag addition in selected files.

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14724#pullrequestreview-1507616881

From cjplummer at openjdk.org  Fri Jun 30 17:48:58 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 30 Jun 2023 17:48:58 GMT
Subject: [jdk21] RFR: 8310380: Handle problems in core-related tests on
 macOS when codesign tool does not work
In-Reply-To: <lIBG-SnwaigKmGPTr0olt-v0RWKnirL-TA5yubgu2BM=.6075f4e2-6f9a-4fc8-8d42-d41fb9d9602f@github.com>
References: <lIBG-SnwaigKmGPTr0olt-v0RWKnirL-TA5yubgu2BM=.6075f4e2-6f9a-4fc8-8d42-d41fb9d9602f@github.com>
Message-ID: <7AuiE6DnZFzTUjtP3IyLiYZsrpKjQHBpfaBpsckI-eo=.aca11b77-6690-462e-b227-82cb90896cd1@github.com>

On Fri, 30 Jun 2023 12:35:27 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> 8310380: Handle problems in core-related tests on macOS when codesign tool does not work

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/87#pullrequestreview-1507621309

From kevinw at openjdk.org  Fri Jun 30 17:53:04 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 30 Jun 2023 17:53:04 GMT
Subject: RFR: 8310993: Missing @since tags in jdk.attach
In-Reply-To: <ZlaGL8Hkom_8l2ypdn5HV_rAhqXmEFQyC6nR391ELPI=.916d1edb-369b-4361-881a-2871f9ee165a@github.com>
References: <ZlaGL8Hkom_8l2ypdn5HV_rAhqXmEFQyC6nR391ELPI=.916d1edb-369b-4361-881a-2871f9ee165a@github.com>
Message-ID: <_S2DtijDQmoKVP2j5Z7C02CbwxS-AvvtDHuqDmuN5Cs=.ab64672c-7264-4a08-af90-60d113ac7ada@github.com>

On Fri, 30 Jun 2023 08:44:22 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Simple since tag addition in selected files.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/14724#issuecomment-1614982322

From kevinw at openjdk.org  Fri Jun 30 17:53:05 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 30 Jun 2023 17:53:05 GMT
Subject: Integrated: 8310993: Missing @since tags in jdk.attach
In-Reply-To: <ZlaGL8Hkom_8l2ypdn5HV_rAhqXmEFQyC6nR391ELPI=.916d1edb-369b-4361-881a-2871f9ee165a@github.com>
References: <ZlaGL8Hkom_8l2ypdn5HV_rAhqXmEFQyC6nR391ELPI=.916d1edb-369b-4361-881a-2871f9ee165a@github.com>
Message-ID: <Wr7eRabC5IiqVdvdBidDFCGkMMCIpgv3IoVhVCEaKJE=.0f8a9396-3ce8-4cb5-88ed-a92f92d7fb7c@github.com>

On Fri, 30 Jun 2023 08:44:22 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Simple since tag addition in selected files.

This pull request has now been integrated.

Changeset: 19601ebe
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/19601ebe9192773a1a47ec3e003b9f1a6808d3de
Stats:     11 lines in 4 files changed: 7 ins; 0 del; 4 mod

8310993: Missing @since tags in jdk.attach

Reviewed-by: sspitsyn, cjplummer

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

PR: https://git.openjdk.org/jdk/pull/14724

From cjplummer at openjdk.org  Fri Jun 30 17:59:55 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 30 Jun 2023 17:59:55 GMT
Subject: RFR: 8303086: SIGSEGV in JavaThread::is_interp_only_mode()
In-Reply-To: <5PhlR3J_Cg-n5DSnX258xNjol34M6eqgTd3AZaoDNsc=.4c7d9382-9f5d-4bdd-b985-7ffc4149da67@github.com>
References: <5PhlR3J_Cg-n5DSnX258xNjol34M6eqgTd3AZaoDNsc=.4c7d9382-9f5d-4bdd-b985-7ffc4149da67@github.com>
Message-ID: <uiRtIcSIEPmuBgcXMM-HZo2HxOm8vArwn9oUdKSrJHc=.c7f0290e-0d31-41aa-af4e-21564d446de7@github.com>

On Fri, 30 Jun 2023 11:27:58 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The JVMTI function `SetEventNotificationMode` can set notification mode globally (`event_thread == nullptr`) for all threads or for a specific thread (`event_thread != nullptr`). To get a stable mount/unmount vision of virtual threads a JvmtiVTMSTransitionDisabler helper object is created :
>     `JvmtiVTMSTransitionDisabler disabler(event_thread);`
> 
> In a case if `event_thread == nullptr` the VTMS transitions are disabled for all virtual thread,
> otherwise they are disabled for a specific thread if it is virtual.
> The call to `JvmtiEventController::set_user_enabled()` makes a call to `recompute_enabled()` at the end of its work to do a required bookkeeping. As part of this work, the `recompute_thread_enabled(state)` is called for each thread from the `ThreadsListHandle`, not only for the given `event_thread`:
> 
>     ThreadsListHandle tlh;
>     for (; state != nullptr; state = state->next()) {
>       any_env_thread_enabled |= recompute_thread_enabled(state);
>     }
> 
> This can cause crashes as VTMS transitions for other virtual threads are allowed.
> Crashes are observed in this small function:
> 
>   bool is_interp_only_mode() {
>     return _thread == nullptr ? _saved_interp_only_mode != 0 : _thread->is_interp_only_mode();
>   }
> 
> In a case `_thread != nullptr` then the call needs to be executed: `_thread->is_interp_only_mode()`.
> But the filed `_thread` can be already changed to `nullptr` by a VTMS transition.
> 
> The fix is to always disable all transitions.
> Thanks to Dan and Patricio for great analysis of this crash!
> 
> Testing:
> - In progress: mach5 tiers 1-6

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14728#pullrequestreview-1507636034

From lmesnik at openjdk.org  Fri Jun 30 19:12:54 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 30 Jun 2023 19:12:54 GMT
Subject: RFR: 8303086: SIGSEGV in JavaThread::is_interp_only_mode()
In-Reply-To: <5PhlR3J_Cg-n5DSnX258xNjol34M6eqgTd3AZaoDNsc=.4c7d9382-9f5d-4bdd-b985-7ffc4149da67@github.com>
References: <5PhlR3J_Cg-n5DSnX258xNjol34M6eqgTd3AZaoDNsc=.4c7d9382-9f5d-4bdd-b985-7ffc4149da67@github.com>
Message-ID: <J1VFtYG1U-d5LgYPH4-1t1wvfikoPdbTSvk8gcnoq9Q=.88d2fcfe-eca4-4a53-ac88-a21648e76f39@github.com>

On Fri, 30 Jun 2023 11:27:58 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The JVMTI function `SetEventNotificationMode` can set notification mode globally (`event_thread == nullptr`) for all threads or for a specific thread (`event_thread != nullptr`). To get a stable mount/unmount vision of virtual threads a JvmtiVTMSTransitionDisabler helper object is created :
>     `JvmtiVTMSTransitionDisabler disabler(event_thread);`
> 
> In a case if `event_thread == nullptr` the VTMS transitions are disabled for all virtual thread,
> otherwise they are disabled for a specific thread if it is virtual.
> The call to `JvmtiEventController::set_user_enabled()` makes a call to `recompute_enabled()` at the end of its work to do a required bookkeeping. As part of this work, the `recompute_thread_enabled(state)` is called for each thread from the `ThreadsListHandle`, not only for the given `event_thread`:
> 
>     ThreadsListHandle tlh;
>     for (; state != nullptr; state = state->next()) {
>       any_env_thread_enabled |= recompute_thread_enabled(state);
>     }
> 
> This can cause crashes as VTMS transitions for other virtual threads are allowed.
> Crashes are observed in this small function:
> 
>   bool is_interp_only_mode() {
>     return _thread == nullptr ? _saved_interp_only_mode != 0 : _thread->is_interp_only_mode();
>   }
> 
> In a case `_thread != nullptr` then the call needs to be executed: `_thread->is_interp_only_mode()`.
> But the filed `_thread` can be already changed to `nullptr` by a VTMS transition.
> 
> The fix is to always disable all transitions.
> Thanks to Dan and Patricio for great analysis of this crash!
> 
> Testing:
> - In progress: mach5 tiers 1-6

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14728#pullrequestreview-1507763983

From dnsimon at openjdk.org  Fri Jun 30 20:13:09 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 30 Jun 2023 20:13:09 GMT
Subject: RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit [v6]
In-Reply-To: <NCCifJKoLoCh0HAXDmEbQhUb2r6LfkfNjy4DfoyHpiw=.c3802651-1189-4a78-b8de-e1d3f01b6ad8@github.com>
References: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
 <PAmaIcD3QoUOkp-XmZG2uhkLgvyJs8altN90PoW4pB4=.37f7fa52-fc02-48b7-9cae-0ed3edc23ed4@github.com>
 <aYRByhmHK3vixOoiNa27btl3VASNg0zPeRNmPXFOGnA=.fe1447ee-ba38-44ef-b34b-4f3b2a57aa72@github.com>
 <NCCifJKoLoCh0HAXDmEbQhUb2r6LfkfNjy4DfoyHpiw=.c3802651-1189-4a78-b8de-e1d3f01b6ad8@github.com>
Message-ID: <8DoPoSlvajUuR94elHaDeES3tl0A02mzM38t3GP3r7s=.ad8c8d2b-608e-4500-afc0-cb6e28961285@github.com>

On Fri, 30 Jun 2023 17:30:33 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> > > But, please, activate GHA testing for this branch.
> > 
> > 
> > Isn't GHA a strict subset of or equal to tier1 mach5 testing? If so, what's the point of doing redundant testing?
> 
> It builds and tests configurations (32-bit) we don't have in our testing.

Good to know - thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/14641#issuecomment-1615144598

From dnsimon at openjdk.org  Fri Jun 30 20:13:11 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 30 Jun 2023 20:13:11 GMT
Subject: RFR: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit [v8]
In-Reply-To: <rD22LkfROcqA7CHJQ87-YqakGn1UrcfHLrZstlEpTro=.74d29a90-b6b8-410b-a7e9-bd89fcb10967@github.com>
References: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
 <rD22LkfROcqA7CHJQ87-YqakGn1UrcfHLrZstlEpTro=.74d29a90-b6b8-410b-a7e9-bd89fcb10967@github.com>
Message-ID: <QF3CgVc96Cn766u2fucOEoVkprk9B3h1RzjtI0VXrwc=.00d0808c-aef3-46a6-94c8-02e56fe98800@github.com>

On Fri, 30 Jun 2023 15:15:16 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> The VMSupport class is required for translating an exception between the HotSpot and libgraal heaps.
>> Loading it lazily can result in a loading exception, obscuring the exception being translated.
>> To avoid this, VMSupport is loaded eagerly along with the other vmClasses.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix warning about conversion from size_t to int - take 2

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/14641#issuecomment-1615145850

From dnsimon at openjdk.org  Fri Jun 30 20:13:12 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Fri, 30 Jun 2023 20:13:12 GMT
Subject: Integrated: 8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in
 ExceptionTranslation::doit
In-Reply-To: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
References: <YL5QADpY5orR_Ab66Tlup9MUlEUZ76vDfIry_WB_3yo=.ccff7dc1-994e-47cb-b67a-d36f3cc024d1@github.com>
Message-ID: <Cbx7jnXNlMJssssIkFLKayTpGsYPZ8Da5Zv_uDX-Yo8=.026c907d-bfaf-4568-a54b-d99633ec64dc@github.com>

On Sun, 25 Jun 2023 06:58:14 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> The VMSupport class is required for translating an exception between the HotSpot and libgraal heaps.
> Loading it lazily can result in a loading exception, obscuring the exception being translated.
> To avoid this, VMSupport is loaded eagerly along with the other vmClasses.

This pull request has now been integrated.

Changeset: f6bdccb4
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f6bdccb45caca0f69918a773a9ad9b2ad91b702f
Stats:     176 lines in 6 files changed: 123 ins; 21 del; 32 mod

8310829: guarantee(!HAS_PENDING_EXCEPTION) failed in ExceptionTranslation::doit

Reviewed-by: never, kvn

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

PR: https://git.openjdk.org/jdk/pull/14641

From amenkov at openjdk.org  Fri Jun 30 20:38:59 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 30 Jun 2023 20:38:59 GMT
Subject: RFR: JDK-8310066: Improve test coverage for JVMTI GetThreadState
 on carrier and mounted vthread [v4]
In-Reply-To: <drX8F0cME_toOtXHddOHAob3pT0v1rCjUpA8QxmEoxY=.03a7d4a3-6526-42b5-b515-bb075d4c664e@github.com>
References: <_8UnxXrT842BKmJ98GlmJyL21yzM0dhGOkeeK0Mnf2g=.c90b2826-922c-4838-b816-8bf3b5933d87@github.com>
 <-FrKWOC5k2JpNUEIZBqUUJk_giziAJ6PWypcG54IdSg=.abbb5539-fb96-40c0-92ec-ac55553ba50b@github.com>
 <drX8F0cME_toOtXHddOHAob3pT0v1rCjUpA8QxmEoxY=.03a7d4a3-6526-42b5-b515-bb075d4c664e@github.com>
Message-ID: <S2-bSsv98GknHcPfNvKlolcjjY8TcrLclrknqSYBYn0=.e2683ede-f012-48e9-a22f-f76f5223a9de@github.com>

On Fri, 30 Jun 2023 05:54:12 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated comment
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadStateMountedTest/libGetThreadStateMountedTest.cpp line 112:
> 
>> 110:       LOG("  ERROR: all expected 'weak' bits are set\n");
>> 111:     }
>> 112:   }
> 
> Nit: I guess, error message at line 110 has to be: 
> `ERROR: not all expected 'weak' bits are set`
> Also, it looks like the check 3a is not really needed as the 3b should cover it.
> But I leave it up to you, if you think check 3a gives some convenience.

'weak' value is for 'sleeping' testcase. In the case we have 2 valid states: JVMTI_THREAD_STATE_SLEEPING and JVMTI_THREAD_STATE_PARKED, but only one of them should be reported.
Test passes expected_weak == JVMTI_THREAD_STATE_SLEEPING | JVMTI_THREAD_STATE_PARKED.
check 3a verifies that at least 1 bit is set (JVMTI_THREAD_STATE_SLEEPING, JVMTI_THREAD_STATE_PARKED or both).
check 3b verifies that only one of the bits is set (i.e. we don't have both JVMTI_THREAD_STATE_SLEEPING and JVMTI_THREAD_STATE_PARKED)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14622#discussion_r1248265672

From sspitsyn at openjdk.org  Fri Jun 30 21:01:09 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 30 Jun 2023 21:01:09 GMT
Subject: RFR: 8303086: SIGSEGV in JavaThread::is_interp_only_mode()
In-Reply-To: <5PhlR3J_Cg-n5DSnX258xNjol34M6eqgTd3AZaoDNsc=.4c7d9382-9f5d-4bdd-b985-7ffc4149da67@github.com>
References: <5PhlR3J_Cg-n5DSnX258xNjol34M6eqgTd3AZaoDNsc=.4c7d9382-9f5d-4bdd-b985-7ffc4149da67@github.com>
Message-ID: <q38LGFZj4NzHuclV1UlLu8MtO6PAa6wrSwjhj5UbxWU=.a102f924-cf4d-483a-b055-564b52fa3bca@github.com>

On Fri, 30 Jun 2023 11:27:58 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The JVMTI function `SetEventNotificationMode` can set notification mode globally (`event_thread == nullptr`) for all threads or for a specific thread (`event_thread != nullptr`). To get a stable mount/unmount vision of virtual threads a JvmtiVTMSTransitionDisabler helper object is created :
>     `JvmtiVTMSTransitionDisabler disabler(event_thread);`
> 
> In a case if `event_thread == nullptr` the VTMS transitions are disabled for all virtual thread,
> otherwise they are disabled for a specific thread if it is virtual.
> The call to `JvmtiEventController::set_user_enabled()` makes a call to `recompute_enabled()` at the end of its work to do a required bookkeeping. As part of this work, the `recompute_thread_enabled(state)` is called for each thread from the `ThreadsListHandle`, not only for the given `event_thread`:
> 
>     ThreadsListHandle tlh;
>     for (; state != nullptr; state = state->next()) {
>       any_env_thread_enabled |= recompute_thread_enabled(state);
>     }
> 
> This can cause crashes as VTMS transitions for other virtual threads are allowed.
> Crashes are observed in this small function:
> 
>   bool is_interp_only_mode() {
>     return _thread == nullptr ? _saved_interp_only_mode != 0 : _thread->is_interp_only_mode();
>   }
> 
> In a case `_thread != nullptr` then the call needs to be executed: `_thread->is_interp_only_mode()`.
> But the filed `_thread` can be already changed to `nullptr` by a VTMS transition.
> 
> The fix is to always disable all transitions.
> Thanks to Dan and Patricio for great analysis of this crash!
> 
> Testing:
> - In progress: mach5 tiers 1-6

Patricio, Chris and Leonid, thank you for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/14728#issuecomment-1615188480

From sspitsyn at openjdk.org  Fri Jun 30 21:01:10 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 30 Jun 2023 21:01:10 GMT
Subject: Integrated: 8303086: SIGSEGV in JavaThread::is_interp_only_mode()
In-Reply-To: <5PhlR3J_Cg-n5DSnX258xNjol34M6eqgTd3AZaoDNsc=.4c7d9382-9f5d-4bdd-b985-7ffc4149da67@github.com>
References: <5PhlR3J_Cg-n5DSnX258xNjol34M6eqgTd3AZaoDNsc=.4c7d9382-9f5d-4bdd-b985-7ffc4149da67@github.com>
Message-ID: <Hh3H9bZX_0cMfLZrxPhaqOF-cncg3dy-WYxP-gEiinY=.5da368fe-4502-44ff-8455-c5e9c518f0a5@github.com>

On Fri, 30 Jun 2023 11:27:58 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The JVMTI function `SetEventNotificationMode` can set notification mode globally (`event_thread == nullptr`) for all threads or for a specific thread (`event_thread != nullptr`). To get a stable mount/unmount vision of virtual threads a JvmtiVTMSTransitionDisabler helper object is created :
>     `JvmtiVTMSTransitionDisabler disabler(event_thread);`
> 
> In a case if `event_thread == nullptr` the VTMS transitions are disabled for all virtual thread,
> otherwise they are disabled for a specific thread if it is virtual.
> The call to `JvmtiEventController::set_user_enabled()` makes a call to `recompute_enabled()` at the end of its work to do a required bookkeeping. As part of this work, the `recompute_thread_enabled(state)` is called for each thread from the `ThreadsListHandle`, not only for the given `event_thread`:
> 
>     ThreadsListHandle tlh;
>     for (; state != nullptr; state = state->next()) {
>       any_env_thread_enabled |= recompute_thread_enabled(state);
>     }
> 
> This can cause crashes as VTMS transitions for other virtual threads are allowed.
> Crashes are observed in this small function:
> 
>   bool is_interp_only_mode() {
>     return _thread == nullptr ? _saved_interp_only_mode != 0 : _thread->is_interp_only_mode();
>   }
> 
> In a case `_thread != nullptr` then the call needs to be executed: `_thread->is_interp_only_mode()`.
> But the filed `_thread` can be already changed to `nullptr` by a VTMS transition.
> 
> The fix is to always disable all transitions.
> Thanks to Dan and Patricio for great analysis of this crash!
> 
> Testing:
> - In progress: mach5 tiers 1-6

This pull request has now been integrated.

Changeset: 971c2efb
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/971c2efb698065c65dcf7373d8c3027f58d5f503
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8303086: SIGSEGV in JavaThread::is_interp_only_mode()

Reviewed-by: pchilanomate, cjplummer, lmesnik

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

PR: https://git.openjdk.org/jdk/pull/14728

From dcubed at openjdk.org  Fri Jun 30 21:14:11 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 30 Jun 2023 21:14:11 GMT
Subject: RFR: 8311186: ProblemList
 javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java
 on linux-aarch64
Message-ID: <5Efv-Uyo3Am0KK1YuN-92jlgkkFxwIu5CPgHzSvKRz4=.e57f9707-8d83-45c7-8ab2-65132402bf0e@github.com>

Trivial ProblemListing/disable changes:
- [JDK-8311186](https://bugs.openjdk.org/browse/JDK-8311186) ProblemList javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java on linux-aarch64
- [JDK-8311189](https://bugs.openjdk.org/browse/JDK-8311189) disable gc/z/TestHighUsage.java
- [JDK-8311190](https://bugs.openjdk.org/browse/JDK-8311190) ProblemList javax/management/remote/mandatory/connection/DeadLockTest.java with virtual threads on windows-x64
- [JDK-8311191](https://bugs.openjdk.org/browse/JDK-8311191) ProblemList javax/management/remote/mandatory/connection/ConnectionTest.java with virtual threads on windows-x64
- [JDK-8311193](https://bugs.openjdk.org/browse/JDK-8311193) ProblemList vmTestbase/nsk/jdb/interrupt/interrupt001/interrupt001.java on linux-all
- [JDK-8311195](https://bugs.openjdk.org/browse/JDK-8311195) ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on macosx-x64

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

Commit messages:
 - 8311195: ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on macosx-x64
 - 8311193: ProblemList vmTestbase/nsk/jdb/interrupt/interrupt001/interrupt001.java on linux-all
 - 8311191: ProblemList javax/management/remote/mandatory/connection/ConnectionTest.java with virtual threads on windows-x64
 - 8311190: ProblemList javax/management/remote/mandatory/connection/DeadLockTest.java with virtual threads on windows-x64
 - 8311189: disable gc/z/TestHighUsage.java
 - 8311186: ProblemList javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java on linux-aarch64

Changes: https://git.openjdk.org/jdk/pull/14741/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14741&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311186
  Stats: 13 lines in 6 files changed: 11 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14741.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14741/head:pull/14741

PR: https://git.openjdk.org/jdk/pull/14741

From lmesnik at openjdk.org  Fri Jun 30 21:33:56 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 30 Jun 2023 21:33:56 GMT
Subject: RFR: 8311186: ProblemList
 javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java
 on linux-aarch64
In-Reply-To: <5Efv-Uyo3Am0KK1YuN-92jlgkkFxwIu5CPgHzSvKRz4=.e57f9707-8d83-45c7-8ab2-65132402bf0e@github.com>
References: <5Efv-Uyo3Am0KK1YuN-92jlgkkFxwIu5CPgHzSvKRz4=.e57f9707-8d83-45c7-8ab2-65132402bf0e@github.com>
Message-ID: <Mb97kpeHZZSucl1HUCIjQPI9BCnukqfxoyOVv_4yM38=.eb508868-ea1b-4670-bcdd-019d08ac02f9@github.com>

On Fri, 30 Jun 2023 19:26:22 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial ProblemListing/disable changes:
> - [JDK-8311186](https://bugs.openjdk.org/browse/JDK-8311186) ProblemList javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java on linux-aarch64
> - [JDK-8311189](https://bugs.openjdk.org/browse/JDK-8311189) disable gc/z/TestHighUsage.java
> - [JDK-8311190](https://bugs.openjdk.org/browse/JDK-8311190) ProblemList javax/management/remote/mandatory/connection/DeadLockTest.java with virtual threads on windows-x64
> - [JDK-8311191](https://bugs.openjdk.org/browse/JDK-8311191) ProblemList javax/management/remote/mandatory/connection/ConnectionTest.java with virtual threads on windows-x64
> - [JDK-8311193](https://bugs.openjdk.org/browse/JDK-8311193) ProblemList vmTestbase/nsk/jdb/interrupt/interrupt001/interrupt001.java on linux-all
> - [JDK-8311195](https://bugs.openjdk.org/browse/JDK-8311195) ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on macosx-x64

I understand that test/hotspot/jtreg/gc/z/TestHighUsage.java can't be problemlisted using zgc test lists. But why not to put into plain ProblemList.txt? 
Also, might be it makes sense to remove it from *zgc problem list while adding ignore? But might be it could be done while fixing bug.

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

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14741#pullrequestreview-1507915619

From dcubed at openjdk.org  Fri Jun 30 21:47:02 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 30 Jun 2023 21:47:02 GMT
Subject: RFR: 8311186: ProblemList
 javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java
 on linux-aarch64
In-Reply-To: <5Efv-Uyo3Am0KK1YuN-92jlgkkFxwIu5CPgHzSvKRz4=.e57f9707-8d83-45c7-8ab2-65132402bf0e@github.com>
References: <5Efv-Uyo3Am0KK1YuN-92jlgkkFxwIu5CPgHzSvKRz4=.e57f9707-8d83-45c7-8ab2-65132402bf0e@github.com>
Message-ID: <bHYDmSRLliDq67eEuyXQGTQrfeG3djuK-wgJIYkCy3A=.bc0a1100-c1e6-4191-9e6f-7a9f9647e31d@github.com>

On Fri, 30 Jun 2023 19:26:22 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial ProblemListing/disable changes:
> - [JDK-8311186](https://bugs.openjdk.org/browse/JDK-8311186) ProblemList javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java on linux-aarch64
> - [JDK-8311189](https://bugs.openjdk.org/browse/JDK-8311189) disable gc/z/TestHighUsage.java
> - [JDK-8311190](https://bugs.openjdk.org/browse/JDK-8311190) ProblemList javax/management/remote/mandatory/connection/DeadLockTest.java with virtual threads on windows-x64
> - [JDK-8311191](https://bugs.openjdk.org/browse/JDK-8311191) ProblemList javax/management/remote/mandatory/connection/ConnectionTest.java with virtual threads on windows-x64
> - [JDK-8311193](https://bugs.openjdk.org/browse/JDK-8311193) ProblemList vmTestbase/nsk/jdb/interrupt/interrupt001/interrupt001.java on linux-all
> - [JDK-8311195](https://bugs.openjdk.org/browse/JDK-8311195) ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on macosx-x64

I guess test/hotspot/jtreg/gc/z/TestHighUsage.java could be added to the
ProblemList.txt file. However, that feels a bit misleading to me. It's a
Generational ZGC only test that can't be ProblemListed in the usual way
by putting it on the Generational ZGC ProblemList.

In this case, I just wanted to be sure that it just doesn't run anywhere for
any reason. Especially after the two previous (bad) ProblemListing attempts.

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

PR Comment: https://git.openjdk.org/jdk/pull/14741#issuecomment-1615220031

From lmesnik at openjdk.org  Fri Jun 30 21:47:03 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 30 Jun 2023 21:47:03 GMT
Subject: RFR: 8311186: ProblemList
 javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java
 on linux-aarch64
In-Reply-To: <5Efv-Uyo3Am0KK1YuN-92jlgkkFxwIu5CPgHzSvKRz4=.e57f9707-8d83-45c7-8ab2-65132402bf0e@github.com>
References: <5Efv-Uyo3Am0KK1YuN-92jlgkkFxwIu5CPgHzSvKRz4=.e57f9707-8d83-45c7-8ab2-65132402bf0e@github.com>
Message-ID: <ol0UVrbgtZ5Yi2XNGWUS7bj3r_WfAnEsC8XIEofvhLc=.27c22a24-42da-4c20-aa78-1543a8dc1e1b@github.com>

On Fri, 30 Jun 2023 19:26:22 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial ProblemListing/disable changes:
> - [JDK-8311186](https://bugs.openjdk.org/browse/JDK-8311186) ProblemList javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java on linux-aarch64
> - [JDK-8311189](https://bugs.openjdk.org/browse/JDK-8311189) disable gc/z/TestHighUsage.java
> - [JDK-8311190](https://bugs.openjdk.org/browse/JDK-8311190) ProblemList javax/management/remote/mandatory/connection/DeadLockTest.java with virtual threads on windows-x64
> - [JDK-8311191](https://bugs.openjdk.org/browse/JDK-8311191) ProblemList javax/management/remote/mandatory/connection/ConnectionTest.java with virtual threads on windows-x64
> - [JDK-8311193](https://bugs.openjdk.org/browse/JDK-8311193) ProblemList vmTestbase/nsk/jdb/interrupt/interrupt001/interrupt001.java on linux-all
> - [JDK-8311195](https://bugs.openjdk.org/browse/JDK-8311195) ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on macosx-x64

There is misunderstanding here. Generational ZGC ProblemList is used not to problemlist Gen ZGC tests, but probleml list any test with -XX:ZGC + Generational enabled execution.

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

PR Comment: https://git.openjdk.org/jdk/pull/14741#issuecomment-1615221446

From dcubed at openjdk.org  Fri Jun 30 21:47:04 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 30 Jun 2023 21:47:04 GMT
Subject: Integrated: 8311186: ProblemList
 javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java
 on linux-aarch64
In-Reply-To: <5Efv-Uyo3Am0KK1YuN-92jlgkkFxwIu5CPgHzSvKRz4=.e57f9707-8d83-45c7-8ab2-65132402bf0e@github.com>
References: <5Efv-Uyo3Am0KK1YuN-92jlgkkFxwIu5CPgHzSvKRz4=.e57f9707-8d83-45c7-8ab2-65132402bf0e@github.com>
Message-ID: <LhJfcug8W4c3toJLh6gURFA2iYIMGyrKp-wnBEMUdx0=.ae249174-8aea-4595-ad77-4ef02494b970@github.com>

On Fri, 30 Jun 2023 19:26:22 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial ProblemListing/disable changes:
> - [JDK-8311186](https://bugs.openjdk.org/browse/JDK-8311186) ProblemList javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java on linux-aarch64
> - [JDK-8311189](https://bugs.openjdk.org/browse/JDK-8311189) disable gc/z/TestHighUsage.java
> - [JDK-8311190](https://bugs.openjdk.org/browse/JDK-8311190) ProblemList javax/management/remote/mandatory/connection/DeadLockTest.java with virtual threads on windows-x64
> - [JDK-8311191](https://bugs.openjdk.org/browse/JDK-8311191) ProblemList javax/management/remote/mandatory/connection/ConnectionTest.java with virtual threads on windows-x64
> - [JDK-8311193](https://bugs.openjdk.org/browse/JDK-8311193) ProblemList vmTestbase/nsk/jdb/interrupt/interrupt001/interrupt001.java on linux-all
> - [JDK-8311195](https://bugs.openjdk.org/browse/JDK-8311195) ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on macosx-x64

This pull request has now been integrated.

Changeset: 140b70fb
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/140b70fb29e2b83e5d33765906ee76a36442a687
Stats:     13 lines in 6 files changed: 11 ins; 2 del; 0 mod

8311186: ProblemList javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java on linux-aarch64
8311189: disable gc/z/TestHighUsage.java
8311190: ProblemList javax/management/remote/mandatory/connection/DeadLockTest.java with virtual threads on windows-x64
8311191: ProblemList javax/management/remote/mandatory/connection/ConnectionTest.java with virtual threads on windows-x64
8311193: ProblemList vmTestbase/nsk/jdb/interrupt/interrupt001/interrupt001.java on linux-all
8311195: ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on macosx-x64

Reviewed-by: lmesnik

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

PR: https://git.openjdk.org/jdk/pull/14741

From dcubed at openjdk.org  Fri Jun 30 22:01:03 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 30 Jun 2023 22:01:03 GMT
Subject: RFR: 8311186: ProblemList
 javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java
 on linux-aarch64
In-Reply-To: <5Efv-Uyo3Am0KK1YuN-92jlgkkFxwIu5CPgHzSvKRz4=.e57f9707-8d83-45c7-8ab2-65132402bf0e@github.com>
References: <5Efv-Uyo3Am0KK1YuN-92jlgkkFxwIu5CPgHzSvKRz4=.e57f9707-8d83-45c7-8ab2-65132402bf0e@github.com>
Message-ID: <-4UUPh9VupNyvb6DuOdo1uh8dGurWBDRbUMvgIVOysg=.476852ae-ba88-40ab-ba9b-0c20738d1005@github.com>

On Fri, 30 Jun 2023 19:26:22 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial ProblemListing/disable changes:
> - [JDK-8311186](https://bugs.openjdk.org/browse/JDK-8311186) ProblemList javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java on linux-aarch64
> - [JDK-8311189](https://bugs.openjdk.org/browse/JDK-8311189) disable gc/z/TestHighUsage.java
> - [JDK-8311190](https://bugs.openjdk.org/browse/JDK-8311190) ProblemList javax/management/remote/mandatory/connection/DeadLockTest.java with virtual threads on windows-x64
> - [JDK-8311191](https://bugs.openjdk.org/browse/JDK-8311191) ProblemList javax/management/remote/mandatory/connection/ConnectionTest.java with virtual threads on windows-x64
> - [JDK-8311193](https://bugs.openjdk.org/browse/JDK-8311193) ProblemList vmTestbase/nsk/jdb/interrupt/interrupt001/interrupt001.java on linux-all
> - [JDK-8311195](https://bugs.openjdk.org/browse/JDK-8311195) ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on macosx-x64

And my point is that the test executes only with Generational ZGC and cannot
always be ProblemListed via the ProblemList-generational-zgc.txt file.

The test internally specifies -XX:+UseZGC and -XX:+ZGenerational, but not
in a way where the ProblemList-generational-zgc.txt file comes into play.

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

PR Comment: https://git.openjdk.org/jdk/pull/14741#issuecomment-1615229673

From amenkov at openjdk.org  Fri Jun 30 22:25:55 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 30 Jun 2023 22:25:55 GMT
Subject: RFR: JDK-8306441: Two-stage Segmented Heap Dump [v14]
In-Reply-To: <5E3RXGlOAWHiPX69pYfbNt8qMfFrHEw0qgtuh4AOmFI=.f8622edb-61fd-430e-9287-2dc864e4e038@github.com>
References: <8YqPPHSW4K1s0t317Kp6UqvoGuv5v9oCbjtQ9FX8p2o=.0f6c687b-d031-401d-901d-1ec532715cdc@github.com>
 <5E3RXGlOAWHiPX69pYfbNt8qMfFrHEw0qgtuh4AOmFI=.f8622edb-61fd-430e-9287-2dc864e4e038@github.com>
Message-ID: <RtMypSvwWhPRnCNctiIzKsrLdZ8ZWvqhWudrc8S_65o=.badd5d5f-0112-4134-9c99-de047226e276@github.com>

On Wed, 28 Jun 2023 08:04:21 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> ### Motivation and proposal
>> Hi, heap dump brings about pauses for application's execution(STW), this is a well-known pain. JDK-8252842 have added parallel support to heapdump in an attempt to alleviate this issue. However, all concurrent threads competitively write heap data to the same file, and more memory is required to maintain the concurrent buffer queue. In experiments, we did not feel a significant performance improvement from that.
>> 
>> The minor-pause solution, which is presented in this PR, is a two-stage segmented heap dump:
>> 
>> 1. Stage One(STW): Concurrent threads directly write data to multiple heap files.
>> 2. Stage Two(Non-STW): Merge multiple heap files into one complete heap dump file.
>> 
>> Now concurrent worker threads are not required to maintain a buffer queue, which would result in more memory overhead, nor do they need to compete for locks. The changes in the overall design are as follows:
>> 
>> ![image](https://github.com/openjdk/jdk/assets/5010047/86d2717d-c621-446f-98c2-cce761ec8db5)
>> <p align="center">Fig1. Before</p>
>> 
>> ![image](https://github.com/openjdk/jdk/assets/5010047/c912c516-83b6-4343-a2e8-5d5bdb99cb87)
>> <p align="center">Fig2. After this patch</p>
>> 
>> ### Performance evaluation
>> | memory | numOfThread | STW         | Total      | Compression |
>> | --- | --------- | -------------- | ------------ | -------- |
>> | 8g | 1 thread | 15.612 secs | 15.612 secs | N |
>> | 8g | 32 thread |  2.5617250 secs | 14.498 secs | N |
>> | 8g | 32 thread | 2.3084878 secs | 3.198 secs | Compress1 |
>> | 8g | 32 thread | 10.9355128 secs | 21.882 secs | Compress2 |
>> | 8g | 96 thread | 2.6790452 secs | 14.012 secs | N |
>> | 8g | 96 thread | 2.3044796 secs | 3.589 secs | Compress1 |
>> | 8g | 96 thread | 9.7585151 secs | 20.219 secs| Compress2 |
>> | 16g | 1 thread | 26.278 secs | 26.278 secs | N |
>> | 16g | 32 thread |  5.2313740 secs | 26.417 secs | N |
>> | 16g | 32 thread | 5.6946983 secs | 6.538 secs | Compress1 |
>> | 16g | 32 thread | 21.8211105 secs | 41.133 secs | Compress2 |
>> | 16g | 96 thread | 6.2445556 secs | 27.141 secs | N |
>> | 16g | 96 thread | 4.6007096 secs | 6.259 secs | Compress1 |
>> | 16g | 96 thread | 19.2965783 secs |  39.007 secs | Compress2 |
>> | 32g | 1 thread | 48.149 secs | 48.149 secs | N |
>> | 32g | 32 thread | 10.7734677 secs | 61.643 secs | N |
>> | 32g | 32 thread | 10.1642097 secs | 10.903 secs | Compress1 |
>> | 32g | 32 thread | 43.8407607 secs | 88.152 secs | Compress2 |
>> | 32g | 96 thread | 13.1522042 ...
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   memory leak

I think commit "use HandshakeClosure instead of VMOperation" is a wrong way to go.
It restricts use of parallel dumping only to attach case.
I have pending changes in heap dumper to support virtual threads and I'm going switch heap dumper to always use DumpMerger.

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

PR Comment: https://git.openjdk.org/jdk/pull/13667#issuecomment-1615243585

From dcubed at openjdk.org  Fri Jun 30 22:27:09 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 30 Jun 2023 22:27:09 GMT
Subject: [jdk21] RFR: 8311186: ProblemList
 javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java
 on linux-aarch64
Message-ID: <WzLABA91v04See3wx5fbvgCeHdixDl3syZle3CztAPI=.ee919516-20e7-42ce-97c1-0988ac33f671@github.com>

Backport 140b70fb29e2b83e5d33765906ee76a36442a687

Trivial ProblemListing/disable changes:

[JDK-8311186](https://bugs.openjdk.org/browse/JDK-8311186) ProblemList javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java on linux-aarch64
[JDK-8311189](https://bugs.openjdk.org/browse/JDK-8311189) disable gc/z/TestHighUsage.java
[JDK-8311190](https://bugs.openjdk.org/browse/JDK-8311190) ProblemList javax/management/remote/mandatory/connection/DeadLockTest.java with virtual threads on windows-x64
[JDK-8311191](https://bugs.openjdk.org/browse/JDK-8311191) ProblemList javax/management/remote/mandatory/connection/ConnectionTest.java with virtual threads on windows-x64
[JDK-8311193](https://bugs.openjdk.org/browse/JDK-8311193) ProblemList vmTestbase/nsk/jdb/interrupt/interrupt001/interrupt001.java on linux-all
[JDK-8311195](https://bugs.openjdk.org/browse/JDK-8311195) ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on macosx-x64

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

Commit messages:
 - Backport 140b70fb29e2b83e5d33765906ee76a36442a687

Changes: https://git.openjdk.org/jdk21/pull/88/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=88&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311186
  Stats: 13 lines in 6 files changed: 11 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk21/pull/88.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/88/head:pull/88

PR: https://git.openjdk.org/jdk21/pull/88

From lmesnik at openjdk.org  Fri Jun 30 22:30:54 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 30 Jun 2023 22:30:54 GMT
Subject: [jdk21] RFR: 8311186: ProblemList
 javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java
 on linux-aarch64
In-Reply-To: <WzLABA91v04See3wx5fbvgCeHdixDl3syZle3CztAPI=.ee919516-20e7-42ce-97c1-0988ac33f671@github.com>
References: <WzLABA91v04See3wx5fbvgCeHdixDl3syZle3CztAPI=.ee919516-20e7-42ce-97c1-0988ac33f671@github.com>
Message-ID: <PFsQPGDPprcqh0D3KbzIkVBi0MSSq9RWBqvQRnTUPOA=.54af3cc7-e6cd-4199-8089-b88cb9c0efb7@github.com>

On Fri, 30 Jun 2023 22:17:40 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Backport 140b70fb29e2b83e5d33765906ee76a36442a687
> 
> Trivial ProblemListing/disable changes:
> 
> [JDK-8311186](https://bugs.openjdk.org/browse/JDK-8311186) ProblemList javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java on linux-aarch64
> [JDK-8311189](https://bugs.openjdk.org/browse/JDK-8311189) disable gc/z/TestHighUsage.java
> [JDK-8311190](https://bugs.openjdk.org/browse/JDK-8311190) ProblemList javax/management/remote/mandatory/connection/DeadLockTest.java with virtual threads on windows-x64
> [JDK-8311191](https://bugs.openjdk.org/browse/JDK-8311191) ProblemList javax/management/remote/mandatory/connection/ConnectionTest.java with virtual threads on windows-x64
> [JDK-8311193](https://bugs.openjdk.org/browse/JDK-8311193) ProblemList vmTestbase/nsk/jdb/interrupt/interrupt001/interrupt001.java on linux-all
> [JDK-8311195](https://bugs.openjdk.org/browse/JDK-8311195) ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on macosx-x64

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk21/pull/88#pullrequestreview-1507948046

From dcubed at openjdk.org  Fri Jun 30 22:33:53 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 30 Jun 2023 22:33:53 GMT
Subject: [jdk21] RFR: 8311186: ProblemList
 javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java
 on linux-aarch64
In-Reply-To: <PFsQPGDPprcqh0D3KbzIkVBi0MSSq9RWBqvQRnTUPOA=.54af3cc7-e6cd-4199-8089-b88cb9c0efb7@github.com>
References: <WzLABA91v04See3wx5fbvgCeHdixDl3syZle3CztAPI=.ee919516-20e7-42ce-97c1-0988ac33f671@github.com>
 <PFsQPGDPprcqh0D3KbzIkVBi0MSSq9RWBqvQRnTUPOA=.54af3cc7-e6cd-4199-8089-b88cb9c0efb7@github.com>
Message-ID: <ApYeW9cTGF-r8Y8yWiWCfInP_Ya5hYT8yuBGLh3lnP4=.ace9501c-83da-4c63-bde5-15a91df9f41c@github.com>

On Fri, 30 Jun 2023 22:28:34 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Backport 140b70fb29e2b83e5d33765906ee76a36442a687
>> 
>> Trivial ProblemListing/disable changes:
>> 
>> [JDK-8311186](https://bugs.openjdk.org/browse/JDK-8311186) ProblemList javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java on linux-aarch64
>> [JDK-8311189](https://bugs.openjdk.org/browse/JDK-8311189) disable gc/z/TestHighUsage.java
>> [JDK-8311190](https://bugs.openjdk.org/browse/JDK-8311190) ProblemList javax/management/remote/mandatory/connection/DeadLockTest.java with virtual threads on windows-x64
>> [JDK-8311191](https://bugs.openjdk.org/browse/JDK-8311191) ProblemList javax/management/remote/mandatory/connection/ConnectionTest.java with virtual threads on windows-x64
>> [JDK-8311193](https://bugs.openjdk.org/browse/JDK-8311193) ProblemList vmTestbase/nsk/jdb/interrupt/interrupt001/interrupt001.java on linux-all
>> [JDK-8311195](https://bugs.openjdk.org/browse/JDK-8311195) ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on macosx-x64
>
> Marked as reviewed by lmesnik (Reviewer).

@lmesnik - Thanks for the fast review!

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

PR Comment: https://git.openjdk.org/jdk21/pull/88#issuecomment-1615247775

From dcubed at openjdk.org  Fri Jun 30 22:37:01 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 30 Jun 2023 22:37:01 GMT
Subject: [jdk21] Integrated: 8311186: ProblemList
 javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java
 on linux-aarch64
In-Reply-To: <WzLABA91v04See3wx5fbvgCeHdixDl3syZle3CztAPI=.ee919516-20e7-42ce-97c1-0988ac33f671@github.com>
References: <WzLABA91v04See3wx5fbvgCeHdixDl3syZle3CztAPI=.ee919516-20e7-42ce-97c1-0988ac33f671@github.com>
Message-ID: <3iX8hQceMK6biOj8SOYxPBrrefYptA77mvkNsv64iwc=.60e786d3-70c2-4a59-8358-284bbb9311c9@github.com>

On Fri, 30 Jun 2023 22:17:40 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Backport 140b70fb29e2b83e5d33765906ee76a36442a687
> 
> Trivial ProblemListing/disable changes:
> 
> [JDK-8311186](https://bugs.openjdk.org/browse/JDK-8311186) ProblemList javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java on linux-aarch64
> [JDK-8311189](https://bugs.openjdk.org/browse/JDK-8311189) disable gc/z/TestHighUsage.java
> [JDK-8311190](https://bugs.openjdk.org/browse/JDK-8311190) ProblemList javax/management/remote/mandatory/connection/DeadLockTest.java with virtual threads on windows-x64
> [JDK-8311191](https://bugs.openjdk.org/browse/JDK-8311191) ProblemList javax/management/remote/mandatory/connection/ConnectionTest.java with virtual threads on windows-x64
> [JDK-8311193](https://bugs.openjdk.org/browse/JDK-8311193) ProblemList vmTestbase/nsk/jdb/interrupt/interrupt001/interrupt001.java on linux-all
> [JDK-8311195](https://bugs.openjdk.org/browse/JDK-8311195) ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on macosx-x64

This pull request has now been integrated.

Changeset: 35d592e3
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/35d592e39d2bc99543d1b6bf671fc73fbef35bc8
Stats:     13 lines in 6 files changed: 11 ins; 2 del; 0 mod

8311186: ProblemList javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java on linux-aarch64
8311189: disable gc/z/TestHighUsage.java
8311190: ProblemList javax/management/remote/mandatory/connection/DeadLockTest.java with virtual threads on windows-x64
8311191: ProblemList javax/management/remote/mandatory/connection/ConnectionTest.java with virtual threads on windows-x64
8311193: ProblemList vmTestbase/nsk/jdb/interrupt/interrupt001/interrupt001.java on linux-all
8311195: ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on macosx-x64

Reviewed-by: lmesnik
Backport-of: 140b70fb29e2b83e5d33765906ee76a36442a687

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

PR: https://git.openjdk.org/jdk21/pull/88