From fyang at openjdk.org  Mon Apr  1 00:22:31 2024
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 1 Apr 2024 00:22:31 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
In-Reply-To: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
References: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
Message-ID: <fV2tjC2mHssR9wsfLolfUUXYEtQRkFohiUmdxsxpyz8=.2828d452-1c47-4dc9-998f-f1334372a2d4@github.com>

On Fri, 29 Mar 2024 19:35:45 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Revert [JDK-8152664](https://bugs.openjdk.org/browse/JDK-8152664) RFE [changes](https://github.com/openjdk/jdk/commit/b853eb7f5ca24eeeda18acbb14287f706499c365) which was used for AOT [JEP 295](https://openjdk.org/jeps/295) implementation in JDK 9. The code was left in HotSpot assuming it will help in a future. But during work on Leyden we decided to not use it. In Leyden cached compiled code will be restored in CodeCache as normal nmethods: no need to change VM's runtime and GC code to process them.
> 
> I may work on optimizing `CodeBlob` and `nmethod` fields layout to reduce header size in separate changes. In these changes I did simple fields reordering to keep small (1 byte) fields together.
> 
> I do not see (and not expected) performance difference with these changes.
> 
> Tested tier1-5, xcomp, stress. Running performance testing.
> 
> I need help with testing on platforms which Oracle does not support.

Hi, I also performed some tests (tier1-3 and hotspot:tier4) on linux-riscv64 platform. Result looks good.

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

PR Comment: https://git.openjdk.org/jdk/pull/18554#issuecomment-2028963874

From jpai at openjdk.org  Mon Apr  1 02:06:51 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 1 Apr 2024 02:06:51 GMT
Subject: RFR: 8328273:
 sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java failed with
 java.rmi.server.ExportException: Port already in use
Message-ID: <3Ls58cgxNjNiZ7jjXlDYmTj-9b7hZl5bXaMZcozwWzE=.6fc146e0-d2e1-4ef1-936d-c6a278e0baa8@github.com>

Can I please get a review of this change which proposes to fix the test failure reported in https://bugs.openjdk.org/browse/JDK-8328273?

As noted in that issue, the `sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java` intermittently fails with a port already in use error. The test attempts to find a free port and then uses it during the test. The interesting part is that the test already has a loop of 10 attempts to retry the test if the port wasn't actually free. So for the test to fail, it would then mean that each of the 10 attempts of using a free port failed (which should be extremely rare and should almost never happen). 

I didn't have an answer for that until today and had it on my TODO to look further. Credit goes to Kevin @kevinjwalls for identifying the issue - turns out this is the exact same issue that Kevin fixed in https://github.com/openjdk/jdk/pull/18470 for a different test. After noticing that fix, I spotted the same typo in the exception message check in this test. That explains why it wasn't retrying at most 10 times. The test was thus immediately failing on first attempt whenever the chosen free port was in use.

I have run this test with a test repeat of 50 with this change and the test now passes always. Without this change and a test repeat of 50, the test failed 2 times. I've additionally searched for any other similar typos in other tests and haven't found any (I searched for the string "Exception thrown by the agent :").

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

Commit messages:
 - 8328273: sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java failed with java.rmi.server.ExportException: Port already in use

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

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

From sspitsyn at openjdk.org  Mon Apr  1 11:29:58 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 1 Apr 2024 11:29:58 GMT
Subject: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed
 with a timeout [v6]
In-Reply-To: <ES7WqD-Q96jSAkvnxdKeEPR6nY8rTmxqpfFaECje7nk=.76f6c761-83a0-490c-907d-a5c1fee141c9@github.com>
References: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>
 <GFoWgbzM0eR7CvL8EVES1XQNHw4FGAOCRL3CqSR1cd0=.a80b41e2-c1c0-4646-b40e-f95a43582113@github.com>
 <8jVAqZX1RFR2qcvbBKILpwrcbXcJ_JCW4_6xm6xlOMc=.5b5c0fb3-5962-4910-a42d-f2ad6e604c00@github.com>
 <ES7WqD-Q96jSAkvnxdKeEPR6nY8rTmxqpfFaECje7nk=.76f6c761-83a0-490c-907d-a5c1fee141c9@github.com>
Message-ID: <_dhsEOkqoGXiZ8enIkUrZiUUmZEX1uRQrRQ51wSZ8QM=.7eb45e4d-e313-4441-a807-1fc8b04a7fd7@github.com>

On Fri, 29 Mar 2024 20:45:14 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest/libPopFrameTest.cpp line 164:
>> 
>>> 162:       fatal(jni, "Main: ensureAtBreakpoint: waited 10 sec");
>>> 163:     }
>>> 164:     LOG("Main: ensureAtBreakpoint: waitig 100 millis\n");
>> 
>> Suggestion:
>> 
>>     LOG("Main: ensureAtBreakpoint: waiting 100 millis\n");
>
> Thanks, Chris. Will fix it.

Fixed and pushed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18419#discussion_r1546232896

From sspitsyn at openjdk.org  Mon Apr  1 11:29:58 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 1 Apr 2024 11:29:58 GMT
Subject: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed
 with a timeout [v7]
In-Reply-To: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>
References: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>
Message-ID: <VQswCx-SO4fn0lclfQ8nb6DVJbqsQc57j1yqn9s2xDU=.491a9ca7-878d-4655-8a65-8a02e93e6214@github.com>

> This PR fixes a synchronization issue in the test:
>   `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest`
>   
> The method `notifyAtBreakpoint()` can notify the `TestTask` thread when it has not reached an expected breakpoint yet.
> The fix is to add a call to the method `ensureAtBreakpoint()` one more time in the `B2` sub-test. It is needed after the top-most frame was popped with the JVMTI `PopFrame`, and the target thread needs to reach the breakpoint again after its execution was resumed.
> 
> The time is very intermittent. At least, I was not able to reproduce the timeout failure in thousands of mach5 runs with the `-Xcomp` option.
> 
> Testing:
>  - Run the test `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest` thousands times in mach5

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

  review: adjusted trap timeout and fixed a typo in comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18419/files
  - new: https://git.openjdk.org/jdk/pull/18419/files/f8344149..21c57eae

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

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

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

From sspitsyn at openjdk.org  Mon Apr  1 11:29:58 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 1 Apr 2024 11:29:58 GMT
Subject: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed
 with a timeout [v4]
In-Reply-To: <TxC-gIhQAhnYgjKHHWNUQNBJGzvoPdSMbOuTOFpT_fk=.bad3d75d-a53b-4941-b293-94fa6693cb6d@github.com>
References: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>
 <opZ7we_--aazbJDsmmunXKpq4ETLHlwaiSmsowDSGi4=.f43fbb97-dcfb-4ffe-a577-8e978c8ec415@github.com>
 <l8zm3rSdUB6JDKODFDXejv5_RrUA_YJraWmIH4tLtQM=.17ebfedb-5ad9-4733-9aa0-647d739feb71@github.com>
 <_7Oa2vFPXsQ_axKlTcLeDrBsSW_q6iuEsRqruErpj8k=.45a5bc91-c9cc-46f5-8fe7-4abbfd34c9b4@github.com>
 <IuK2HZd9luuh7D6DwrhW21zRy1gn38fMVWcA2vJuQhE=.caa13016-af40-4d38-8b68-6f35a793b37f@github.com>
 <UtHFXIRXIM0bfJjSQab0Aek3WM_CHjAyEDU6GWQNaTM=.1f9f3ac1-42fa-4cfd-aaa6-fad99f9050c1@github.com>
 <bwq7M7lUiCRWA1oKy90K0CHBs3--BTKcdwxzQXUQCA4=.95855656-b272-493e-bd0d-7565c95e3f20@github.com>
 <NxMMqvpK4L_QeBcfMBDPg4hmPOWWBU0Jx_mPrlZrHfc=.90c2daae-85be-4329-ab92-8eb74a4b0645@github.com>
 <ticDOo4d_kGcyuU4T7Qd-oOlbupwnncY-31vX5bYMQs=.5b70d652-b5b0-4a14-a92a-5c84bdb5a2f6@github.com>
 <TxC-gIhQAhnYgjKHHWNUQNBJGzvoPdSMbOuTOFpT_fk=.bad3d75d-a53b-4941-b293-94fa6693cb6d@github.com>
Message-ID: <wE7pcD3c5giuvG1jV5ocxGvVPdIdrg9U52nQsO7NbC8=.290f9efd-339c-4441-a2f8-943313d84e28@github.com>

On Sat, 30 Mar 2024 01:32:27 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> It wait for some increment of time upto a maximum of 100 seconds.
>
> I'm good with that. Thanks for clarifying.

Thanks, Dan.
I've decided to increase this timeout to 20 secs. Pushed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18419#discussion_r1546232711

From amitkumar at openjdk.org  Mon Apr  1 12:07:31 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Mon, 1 Apr 2024 12:07:31 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
In-Reply-To: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
References: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
Message-ID: <sYoiBxrL8P1iII2LnIoXhajUVbjdOrAhxIyOdSeRbAg=.f6004f6a-34df-4de7-9ce9-9f8b65344045@github.com>

On Fri, 29 Mar 2024 19:35:45 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Revert [JDK-8152664](https://bugs.openjdk.org/browse/JDK-8152664) RFE [changes](https://github.com/openjdk/jdk/commit/b853eb7f5ca24eeeda18acbb14287f706499c365) which was used for AOT [JEP 295](https://openjdk.org/jeps/295) implementation in JDK 9. The code was left in HotSpot assuming it will help in a future. But during work on Leyden we decided to not use it. In Leyden cached compiled code will be restored in CodeCache as normal nmethods: no need to change VM's runtime and GC code to process them.
> 
> I may work on optimizing `CodeBlob` and `nmethod` fields layout to reduce header size in separate changes. In these changes I did simple fields reordering to keep small (1 byte) fields together.
> 
> I do not see (and not expected) performance difference with these changes.
> 
> Tested tier1-5, xcomp, stress. Running performance testing.
> 
> I need help with testing on platforms which Oracle does not support.

I performed the build + testing `{fastdebug, release, slowdebug} X {tier1}`  on `s390x` and result looks fine.

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

PR Comment: https://git.openjdk.org/jdk/pull/18554#issuecomment-2029655163

From coleenp at openjdk.org  Mon Apr  1 12:15:57 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 1 Apr 2024 12:15:57 GMT
Subject: RFR: 8313332: Simplify lazy jmethodID cache in InstanceKlass
Message-ID: <OnCG3ISfuvt7bIZaKL5fV8PTaZe8KWs56IWc0XdeoYo=.9d61355a-a4fe-4f6c-9a12-805a9f1febc5@github.com>

This change simplifies the code that grows the jmethodID cache in InstanceKlass.  Instead of lazily, when there's a rare request for a jmethodID for an obsolete method, the jmethodID cache is grown during the RedefineClasses safepoint.  The InstanceKlass's jmethodID cache is lazily allocated when there's a jmethodID allocated, so not every InstanceKlass has a cache, but the growth now only happens in a safepoint.  This code will become racy with the potential change for deallocating jmethodIDs.

Tested with tier1-4, vmTestbase/nsk/jvmti java/lang/instrument tests (in case they're not in tier1-4).

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

Commit messages:
 - Add Safepoint assert, don't use order accessors because they're not needed.
 - 8313332: Simplify lazy jmethodID cache in InstanceKlass

Changes: https://git.openjdk.org/jdk/pull/18549/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18549&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313332
  Stats: 222 lines in 7 files changed: 41 ins; 144 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/18549.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18549/head:pull/18549

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

From cjplummer at openjdk.org  Mon Apr  1 17:58:30 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 1 Apr 2024 17:58:30 GMT
Subject: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed
 with a timeout [v7]
In-Reply-To: <VQswCx-SO4fn0lclfQ8nb6DVJbqsQc57j1yqn9s2xDU=.491a9ca7-878d-4655-8a65-8a02e93e6214@github.com>
References: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>
 <VQswCx-SO4fn0lclfQ8nb6DVJbqsQc57j1yqn9s2xDU=.491a9ca7-878d-4655-8a65-8a02e93e6214@github.com>
Message-ID: <jNAKGLDMFA7eY-rU8XpHqqkcUHwemyzhQ7Ua870MsHQ=.2563049c-8020-4b48-bd2a-6b25467b6d79@github.com>

On Mon, 1 Apr 2024 11:29:58 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This PR fixes a synchronization issue in the test:
>>   `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest`
>>   
>> The method `notifyAtBreakpoint()` can notify the `TestTask` thread when it has not reached an expected breakpoint yet.
>> The fix is to add a call to the method `ensureAtBreakpoint()` one more time in the `B2` sub-test. It is needed after the top-most frame was popped with the JVMTI `PopFrame`, and the target thread needs to reach the breakpoint again after its execution was resumed.
>> 
>> The time is very intermittent. At least, I was not able to reproduce the timeout failure in thousands of mach5 runs with the `-Xcomp` option.
>> 
>> Testing:
>>  - Run the test `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest` thousands times in mach5
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: adjusted trap timeout and fixed a typo in comment

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18419#pullrequestreview-1971806536

From dlong at openjdk.org  Mon Apr  1 18:18:00 2024
From: dlong at openjdk.org (Dean Long)
Date: Mon, 1 Apr 2024 18:18:00 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
In-Reply-To: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
References: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
Message-ID: <h-K6s_srneCwfdQEalwLzuBDBhS-qobQet-XVPbg8BM=.677c7770-7b3c-4925-bfad-638e455f44eb@github.com>

On Fri, 29 Mar 2024 19:35:45 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Revert [JDK-8152664](https://bugs.openjdk.org/browse/JDK-8152664) RFE [changes](https://github.com/openjdk/jdk/commit/b853eb7f5ca24eeeda18acbb14287f706499c365) which was used for AOT [JEP 295](https://openjdk.org/jeps/295) implementation in JDK 9. The code was left in HotSpot assuming it will help in a future. But during work on Leyden we decided to not use it. In Leyden cached compiled code will be restored in CodeCache as normal nmethods: no need to change VM's runtime and GC code to process them.
> 
> I may work on optimizing `CodeBlob` and `nmethod` fields layout to reduce header size in separate changes. In these changes I did simple fields reordering to keep small (1 byte) fields together.
> 
> I do not see (and not expected) performance difference with these changes.
> 
> Tested tier1-5, xcomp, stress. Running performance testing.
> 
> I need help with testing on platforms which Oracle does not support.

The `not_used` state was introduced for AOT.  It can go away now.

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

PR Comment: https://git.openjdk.org/jdk/pull/18554#issuecomment-2030282409

From kvn at openjdk.org  Mon Apr  1 19:38:59 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 1 Apr 2024 19:38:59 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
In-Reply-To: <fV2tjC2mHssR9wsfLolfUUXYEtQRkFohiUmdxsxpyz8=.2828d452-1c47-4dc9-998f-f1334372a2d4@github.com>
References: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
 <fV2tjC2mHssR9wsfLolfUUXYEtQRkFohiUmdxsxpyz8=.2828d452-1c47-4dc9-998f-f1334372a2d4@github.com>
Message-ID: <AJ3suZNm4uB8ia5CX8HFNHVUjxNd6gVhlf-3NC4PdKQ=.c9d8611b-767a-4988-b42c-7a5954fa29b6@github.com>

On Mon, 1 Apr 2024 00:19:32 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Revert [JDK-8152664](https://bugs.openjdk.org/browse/JDK-8152664) RFE [changes](https://github.com/openjdk/jdk/commit/b853eb7f5ca24eeeda18acbb14287f706499c365) which was used for AOT [JEP 295](https://openjdk.org/jeps/295) implementation in JDK 9. The code was left in HotSpot assuming it will help in a future. But during work on Leyden we decided to not use it. In Leyden cached compiled code will be restored in CodeCache as normal nmethods: no need to change VM's runtime and GC code to process them.
>> 
>> I may work on optimizing `CodeBlob` and `nmethod` fields layout to reduce header size in separate changes. In these changes I did simple fields reordering to keep small (1 byte) fields together.
>> 
>> I do not see (and not expected) performance difference with these changes.
>> 
>> Tested tier1-5, xcomp, stress. Running performance testing.
>> 
>> I need help with testing on platforms which Oracle does not support.
>
> Hi, I also performed some tests (tier1-3 and hotspot:tier4) on linux-riscv64 platform. Result looks good.

@RealFYang and @offamitkumar  thank you for testing.

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

PR Comment: https://git.openjdk.org/jdk/pull/18554#issuecomment-2030425253

From sspitsyn at openjdk.org  Mon Apr  1 19:45:04 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 1 Apr 2024 19:45:04 GMT
Subject: RFR: 8328665: serviceability/jvmti/vthread/PopFrameTest failed
 with a timeout [v7]
In-Reply-To: <VQswCx-SO4fn0lclfQ8nb6DVJbqsQc57j1yqn9s2xDU=.491a9ca7-878d-4655-8a65-8a02e93e6214@github.com>
References: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>
 <VQswCx-SO4fn0lclfQ8nb6DVJbqsQc57j1yqn9s2xDU=.491a9ca7-878d-4655-8a65-8a02e93e6214@github.com>
Message-ID: <4vO-siiumLdKNUbtjNOPOkK96_1xhrUVSssxd-37iRQ=.22fef65e-08ea-47de-8710-92bd3f32dff3@github.com>

On Mon, 1 Apr 2024 11:29:58 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This PR fixes a synchronization issue in the test:
>>   `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest`
>>   
>> The method `notifyAtBreakpoint()` can notify the `TestTask` thread when it has not reached an expected breakpoint yet.
>> The fix is to add a call to the method `ensureAtBreakpoint()` one more time in the `B2` sub-test. It is needed after the top-most frame was popped with the JVMTI `PopFrame`, and the target thread needs to reach the breakpoint again after its execution was resumed.
>> 
>> The time is very intermittent. At least, I was not able to reproduce the timeout failure in thousands of mach5 runs with the `-Xcomp` option.
>> 
>> Testing:
>>  - Run the test `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest` thousands times in mach5
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: adjusted trap timeout and fixed a typo in comment

Thank you for review, Chris.

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

PR Comment: https://git.openjdk.org/jdk/pull/18419#issuecomment-2030434649

From kvn at openjdk.org  Mon Apr  1 19:52:59 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 1 Apr 2024 19:52:59 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
In-Reply-To: <h-K6s_srneCwfdQEalwLzuBDBhS-qobQet-XVPbg8BM=.677c7770-7b3c-4925-bfad-638e455f44eb@github.com>
References: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
 <h-K6s_srneCwfdQEalwLzuBDBhS-qobQet-XVPbg8BM=.677c7770-7b3c-4925-bfad-638e455f44eb@github.com>
Message-ID: <sLjbfVsKam-tp2xp5IJMlZPP58YZ1kZsMDuE0-LDwzQ=.48b59aa2-89a0-47e4-9d2d-fea699b4babf@github.com>

On Mon, 1 Apr 2024 18:15:43 GMT, Dean Long <dlong at openjdk.org> wrote:

> The `not_used` state was introduced for AOT. It can go away now.

Good catch, Dean.

I want to keep `nmethod::make_not_used()` method because we use it in Leyden to keep AOT code (outside of CodeCache): [nmethod.hpp#L476](https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/code/nmethod.hpp#L476)
It does not use this flag value.

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

PR Comment: https://git.openjdk.org/jdk/pull/18554#issuecomment-2030448462

From dcubed at openjdk.org  Mon Apr  1 21:00:59 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 1 Apr 2024 21:00:59 GMT
Subject: RFR: 8328273:
 sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java failed with
 java.rmi.server.ExportException: Port already in use
In-Reply-To: <3Ls58cgxNjNiZ7jjXlDYmTj-9b7hZl5bXaMZcozwWzE=.6fc146e0-d2e1-4ef1-936d-c6a278e0baa8@github.com>
References: <3Ls58cgxNjNiZ7jjXlDYmTj-9b7hZl5bXaMZcozwWzE=.6fc146e0-d2e1-4ef1-936d-c6a278e0baa8@github.com>
Message-ID: <g0erBjRtRY7Z2dfEY6urG_yyFIvgehBPVAy4eHMBfjg=.ab939504-1d53-4a9b-ac6f-3fbf9c2bb5e1@github.com>

On Mon, 1 Apr 2024 02:02:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the test failure reported in https://bugs.openjdk.org/browse/JDK-8328273?
> 
> As noted in that issue, the `sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java` intermittently fails with a port already in use error. The test attempts to find a free port and then uses it during the test. The interesting part is that the test already has a loop of 10 attempts to retry the test if the port wasn't actually free. So for the test to fail, it would then mean that each of the 10 attempts of using a free port failed (which should be extremely rare and should almost never happen). 
> 
> I didn't have an answer for that until today and had it on my TODO to look further. Credit goes to Kevin @kevinjwalls for identifying the issue - turns out this is the exact same issue that Kevin fixed in https://github.com/openjdk/jdk/pull/18470 for a different test. After noticing that fix, I spotted the same typo in the exception message check in this test. That explains why it wasn't retrying at most 10 times. The test was thus immediately failing on first attempt whenever the chosen free port was in use.
> 
> I have run this test with a test repeat of 50 with this change and the test now passes always. Without this change and a test repeat of 50, the test failed 2 times. I've additionally searched for any other similar typos in other tests and haven't found any (I searched for the string "Exception thrown by the agent :").

Thumbs up. This is a trivial fix.

@jaikiran - Thanks for fixing this bug!!

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

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18561#pullrequestreview-1972108656

From kvn at openjdk.org  Mon Apr  1 21:07:31 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 1 Apr 2024 21:07:31 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
 [v2]
In-Reply-To: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
References: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
Message-ID: <eMUTt2ic_OBuS168USvarGBRDCquzLb9AxrSpog1TZw=.d9ae808b-ed03-4971-bd13-db48794a1024@github.com>

> Revert [JDK-8152664](https://bugs.openjdk.org/browse/JDK-8152664) RFE [changes](https://github.com/openjdk/jdk/commit/b853eb7f5ca24eeeda18acbb14287f706499c365) which was used for AOT [JEP 295](https://openjdk.org/jeps/295) implementation in JDK 9. The code was left in HotSpot assuming it will help in a future. But during work on Leyden we decided to not use it. In Leyden cached compiled code will be restored in CodeCache as normal nmethods: no need to change VM's runtime and GC code to process them.
> 
> I may work on optimizing `CodeBlob` and `nmethod` fields layout to reduce header size in separate changes. In these changes I did simple fields reordering to keep small (1 byte) fields together.
> 
> I do not see (and not expected) performance difference with these changes.
> 
> Tested tier1-5, xcomp, stress. Running performance testing.
> 
> I need help with testing on platforms which Oracle does not support.

Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  Removed not_used state of nmethod

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18554/files
  - new: https://git.openjdk.org/jdk/pull/18554/files/7635b333..246ff68a

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

  Stats: 5 lines in 2 files changed: 0 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18554.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18554/head:pull/18554

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

From kvn at openjdk.org  Mon Apr  1 21:12:00 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 1 Apr 2024 21:12:00 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
 [v2]
In-Reply-To: <eMUTt2ic_OBuS168USvarGBRDCquzLb9AxrSpog1TZw=.d9ae808b-ed03-4971-bd13-db48794a1024@github.com>
References: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
 <eMUTt2ic_OBuS168USvarGBRDCquzLb9AxrSpog1TZw=.d9ae808b-ed03-4971-bd13-db48794a1024@github.com>
Message-ID: <fgr3lz6qjcCs0zfbG-4-llRlAr3zz9RfaizEj58-QBo=.c26d1ba0-c833-4288-b641-d1b372a081bb@github.com>

On Mon, 1 Apr 2024 21:07:31 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Revert [JDK-8152664](https://bugs.openjdk.org/browse/JDK-8152664) RFE [changes](https://github.com/openjdk/jdk/commit/b853eb7f5ca24eeeda18acbb14287f706499c365) which was used for AOT [JEP 295](https://openjdk.org/jeps/295) implementation in JDK 9. The code was left in HotSpot assuming it will help in a future. But during work on Leyden we decided to not use it. In Leyden cached compiled code will be restored in CodeCache as normal nmethods: no need to change VM's runtime and GC code to process them.
>> 
>> I may work on optimizing `CodeBlob` and `nmethod` fields layout to reduce header size in separate changes. In these changes I did simple fields reordering to keep small (1 byte) fields together.
>> 
>> I do not see (and not expected) performance difference with these changes.
>> 
>> Tested tier1-5, xcomp, stress. Running performance testing.
>> 
>> I need help with testing on platforms which Oracle does not support.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed not_used state of nmethod

I did not change `src/hotspot/share/code//codeHeapState.cpp` code which counts nmethods with `not_used` state by checking `(!nm->is_not_entrant()` after `(nm->is_in_use())`.  Removing `not_used` does not affect it.
The code is complicated and needs separate RFE if we decide to clean it.

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

PR Comment: https://git.openjdk.org/jdk/pull/18554#issuecomment-2030560338

From dcubed at openjdk.org  Mon Apr  1 22:19:06 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 1 Apr 2024 22:19:06 GMT
Subject: RFR: 8329425: ProblemList containers/docker/TestJFREvents.java on
 linux-x64
Message-ID: <4IV494kBFp8o93ikOFJEWQMsXtWXfh4EsThZ8fSIsKE=.c6d109e4-d1a4-4140-9ad7-96e6cbaa6eb1@github.com>

Trivial fixes to ProblemList noisy tests:

[JDK-8329425](https://bugs.openjdk.org/browse/JDK-8329425) ProblemList containers/docker/TestJFREvents.java on linux-x64
[JDK-8329426](https://bugs.openjdk.org/browse/JDK-8329426) ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on windows-x64
[JDK-8329427](https://bugs.openjdk.org/browse/JDK-8329427) ProblemList javax/sound/sampled/Clip/ClipFlushCrash.java on linux-x64
[JDK-8329428](https://bugs.openjdk.org/browse/JDK-8329428) ProblemList vmTestbase/nsk/stress/thread/thread006.java on linux-all in Xcomp

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

Commit messages:
 - 8329428: ProblemList vmTestbase/nsk/stress/thread/thread006.java on linux-all in Xcomp
 - 8329427: ProblemList javax/sound/sampled/Clip/ClipFlushCrash.java on linux-x64
 - 8329426: ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on windows-x64
 - 8329425: ProblemList containers/docker/TestJFREvents.java on linux-x64

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

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

From dholmes at openjdk.org  Mon Apr  1 22:19:07 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 1 Apr 2024 22:19:07 GMT
Subject: RFR: 8329425: ProblemList containers/docker/TestJFREvents.java on
 linux-x64
In-Reply-To: <4IV494kBFp8o93ikOFJEWQMsXtWXfh4EsThZ8fSIsKE=.c6d109e4-d1a4-4140-9ad7-96e6cbaa6eb1@github.com>
References: <4IV494kBFp8o93ikOFJEWQMsXtWXfh4EsThZ8fSIsKE=.c6d109e4-d1a4-4140-9ad7-96e6cbaa6eb1@github.com>
Message-ID: <q-Mr1JtFWiWhBUaGPaM8BCop8Rln9up-Sq5IR4iwyag=.f689662f-aa4c-47c1-9ce8-73dd756ebc9c@github.com>

On Mon, 1 Apr 2024 21:07:34 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial fixes to ProblemList noisy tests:
> 
> [JDK-8329425](https://bugs.openjdk.org/browse/JDK-8329425) ProblemList containers/docker/TestJFREvents.java on linux-x64
> [JDK-8329426](https://bugs.openjdk.org/browse/JDK-8329426) ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on windows-x64
> [JDK-8329427](https://bugs.openjdk.org/browse/JDK-8329427) ProblemList javax/sound/sampled/Clip/ClipFlushCrash.java on linux-x64
> [JDK-8329428](https://bugs.openjdk.org/browse/JDK-8329428) ProblemList vmTestbase/nsk/stress/thread/thread006.java on linux-all in Xcomp

Seems okay. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18568#pullrequestreview-1972236395

From dcubed at openjdk.org  Mon Apr  1 22:25:06 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 1 Apr 2024 22:25:06 GMT
Subject: RFR: 8329425: ProblemList containers/docker/TestJFREvents.java on
 linux-x64
In-Reply-To: <q-Mr1JtFWiWhBUaGPaM8BCop8Rln9up-Sq5IR4iwyag=.f689662f-aa4c-47c1-9ce8-73dd756ebc9c@github.com>
References: <4IV494kBFp8o93ikOFJEWQMsXtWXfh4EsThZ8fSIsKE=.c6d109e4-d1a4-4140-9ad7-96e6cbaa6eb1@github.com>
 <q-Mr1JtFWiWhBUaGPaM8BCop8Rln9up-Sq5IR4iwyag=.f689662f-aa4c-47c1-9ce8-73dd756ebc9c@github.com>
Message-ID: <ktN8Vs7ylk1iJ7204chIi0srcHl_3S-TdurRe2eRsSQ=.28127285-761b-49f9-9816-d979167d781b@github.com>

On Mon, 1 Apr 2024 22:15:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Trivial fixes to ProblemList noisy tests:
>> 
>> [JDK-8329425](https://bugs.openjdk.org/browse/JDK-8329425) ProblemList containers/docker/TestJFREvents.java on linux-x64
>> [JDK-8329426](https://bugs.openjdk.org/browse/JDK-8329426) ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on windows-x64
>> [JDK-8329427](https://bugs.openjdk.org/browse/JDK-8329427) ProblemList javax/sound/sampled/Clip/ClipFlushCrash.java on linux-x64
>> [JDK-8329428](https://bugs.openjdk.org/browse/JDK-8329428) ProblemList vmTestbase/nsk/stress/thread/thread006.java on linux-all in Xcomp
>
> Seems okay. Thanks

@dholmes-ora - Thanks for the lightning fast review!

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

PR Comment: https://git.openjdk.org/jdk/pull/18568#issuecomment-2030672631

From dcubed at openjdk.org  Mon Apr  1 22:25:07 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 1 Apr 2024 22:25:07 GMT
Subject: Integrated: 8329425: ProblemList containers/docker/TestJFREvents.java
 on linux-x64
In-Reply-To: <4IV494kBFp8o93ikOFJEWQMsXtWXfh4EsThZ8fSIsKE=.c6d109e4-d1a4-4140-9ad7-96e6cbaa6eb1@github.com>
References: <4IV494kBFp8o93ikOFJEWQMsXtWXfh4EsThZ8fSIsKE=.c6d109e4-d1a4-4140-9ad7-96e6cbaa6eb1@github.com>
Message-ID: <9d0JDigfqBMaHdGS17bfqOTt0bCI4k474KSe4GcfXdU=.cc7c5d99-e1b7-417c-9bfd-a6142a571800@github.com>

On Mon, 1 Apr 2024 21:07:34 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial fixes to ProblemList noisy tests:
> 
> [JDK-8329425](https://bugs.openjdk.org/browse/JDK-8329425) ProblemList containers/docker/TestJFREvents.java on linux-x64
> [JDK-8329426](https://bugs.openjdk.org/browse/JDK-8329426) ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on windows-x64
> [JDK-8329427](https://bugs.openjdk.org/browse/JDK-8329427) ProblemList javax/sound/sampled/Clip/ClipFlushCrash.java on linux-x64
> [JDK-8329428](https://bugs.openjdk.org/browse/JDK-8329428) ProblemList vmTestbase/nsk/stress/thread/thread006.java on linux-all in Xcomp

This pull request has now been integrated.

Changeset: c2979c15
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c2979c150bdbcc2a9e6026347dc590e6a7e86595
Stats:     5 lines in 3 files changed: 4 ins; 0 del; 1 mod

8329425: ProblemList containers/docker/TestJFREvents.java on linux-x64
8329426: ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on windows-x64
8329427: ProblemList javax/sound/sampled/Clip/ClipFlushCrash.java on linux-x64
8329428: ProblemList vmTestbase/nsk/stress/thread/thread006.java on linux-all in Xcomp

Reviewed-by: dholmes

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

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

From amenkov at openjdk.org  Mon Apr  1 23:30:59 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 1 Apr 2024 23:30:59 GMT
Subject: RFR: 8313332: Simplify lazy jmethodID cache in InstanceKlass
In-Reply-To: <OnCG3ISfuvt7bIZaKL5fV8PTaZe8KWs56IWc0XdeoYo=.9d61355a-a4fe-4f6c-9a12-805a9f1febc5@github.com>
References: <OnCG3ISfuvt7bIZaKL5fV8PTaZe8KWs56IWc0XdeoYo=.9d61355a-a4fe-4f6c-9a12-805a9f1febc5@github.com>
Message-ID: <QZLRVr42XzM2LyHrnnZjZuDoOxUzRZWFHhaEyuasuaY=.67184348-7add-445c-a06a-506887874d78@github.com>

On Fri, 29 Mar 2024 15:25:48 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change simplifies the code that grows the jmethodID cache in InstanceKlass.  Instead of lazily, when there's a rare request for a jmethodID for an obsolete method, the jmethodID cache is grown during the RedefineClasses safepoint.  The InstanceKlass's jmethodID cache is lazily allocated when there's a jmethodID allocated, so not every InstanceKlass has a cache, but the growth now only happens in a safepoint.  This code will become racy with the potential change for deallocating jmethodIDs.
> 
> Tested with tier1-4, vmTestbase/nsk/jvmti java/lang/instrument tests (in case they're not in tier1-4).

Looks like good simplification

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

Marked as reviewed by amenkov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18549#pullrequestreview-1972336247

From sspitsyn at openjdk.org  Mon Apr  1 23:40:03 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 1 Apr 2024 23:40:03 GMT
Subject: Integrated: 8328665: serviceability/jvmti/vthread/PopFrameTest failed
 with a timeout
In-Reply-To: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>
References: <hRvuWwKctXjd9ZarLPBnXaGStMQ5GacP8JZG50sBeXQ=.0c5665d5-859e-4bb4-b032-cf232044fa3a@github.com>
Message-ID: <WAQw1OFCbdgBtD_jK7GxdujZ5lrK5xm4r2AayOOZw8I=.751d60a0-eb1c-471a-a376-2243ca113d1b@github.com>

On Thu, 21 Mar 2024 07:11:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This PR fixes a synchronization issue in the test:
>   `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest`
>   
> The method `notifyAtBreakpoint()` can notify the `TestTask` thread when it has not reached an expected breakpoint yet.
> The fix is to add a call to the method `ensureAtBreakpoint()` one more time in the `B2` sub-test. It is needed after the top-most frame was popped with the JVMTI `PopFrame`, and the target thread needs to reach the breakpoint again after its execution was resumed.
> 
> The time is very intermittent. At least, I was not able to reproduce the timeout failure in thousands of mach5 runs with the `-Xcomp` option.
> 
> Testing:
>  - Run the test `test/hotspot/jtreg/serviceability/jvmti/vthread/PopFrameTest` thousands times in mach5

This pull request has now been integrated.

Changeset: 70c8ff1c
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/70c8ff1c9a9adf21a16d8a6b4da1eeec65afe61d
Stats:     17 lines in 1 file changed: 9 ins; 2 del; 6 mod

8328665: serviceability/jvmti/vthread/PopFrameTest failed with a timeout

Reviewed-by: lmesnik, cjplummer

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

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

From sspitsyn at openjdk.org  Tue Apr  2 00:29:18 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 2 Apr 2024 00:29:18 GMT
Subject: RFR: 8329432: PopFrame and ForceEarlyReturn functions should use
 JvmtiHandshake
Message-ID: <5tcPHZX0nNTHbQqZfHRl2riTpJglQyGJ2hRJXyIMZPY=.4de7ac6d-dd84-4943-bab1-5dba67bf5cf0@github.com>

The internal JVM TI `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor JVM TI functions `PopFrame` and `ForceEarlyReturn` on the base of `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes.

Testing:

    Ran mach5 tiers 1-6

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

Commit messages:
 - 8329432: PopFrame and ForceEarlyReturn functions should use JvmtiHandshake

Changes: https://git.openjdk.org/jdk/pull/18570/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18570&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329432
  Stats: 41 lines in 3 files changed: 13 ins; 20 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/18570.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18570/head:pull/18570

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

From amenkov at openjdk.org  Tue Apr  2 01:05:07 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 2 Apr 2024 01:05:07 GMT
Subject: RFR: JDK-8322042: HeapDumper should perform merge on the current
 thread instead of VMThread
In-Reply-To: <4--MamzddI0M3jpWu5NG1OvvX2aOo1vTUsH0TNYmty0=.9c4f04fc-2809-427f-9109-6a2f8be3ca5a@github.com>
References: <4--MamzddI0M3jpWu5NG1OvvX2aOo1vTUsH0TNYmty0=.9c4f04fc-2809-427f-9109-6a2f8be3ca5a@github.com>
Message-ID: <vSEg9lGBV5kRfTHDIZkmhn9yjGYbZSoPCJWhQUtVPk0=.565b3228-4432-415a-b1ab-844f21ef217e@github.com>

On Tue, 2 Apr 2024 00:40:37 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updated HeapDumper to always perform merge on the current thread.
> 
> Testing: tier1-5, all HeapDump-related tests
>   Covered heap dumping scenarios:
>     - `jcmd GC.heap_dump` command;
>     - `HotSpotDiagnosticMXBean.dumpHeap()`;
>     - `HeapDumpBeforeFullGC`, `HeapDumpAfterFullGC` VM options;
>     - `HeapDumpOnOutOfMemoryError` VM option.

added serviceability label

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

PR Comment: https://git.openjdk.org/jdk/pull/18571#issuecomment-2030892178

From jpai at openjdk.org  Tue Apr  2 01:11:58 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Apr 2024 01:11:58 GMT
Subject: RFR: 8328273:
 sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java failed with
 java.rmi.server.ExportException: Port already in use
In-Reply-To: <3Ls58cgxNjNiZ7jjXlDYmTj-9b7hZl5bXaMZcozwWzE=.6fc146e0-d2e1-4ef1-936d-c6a278e0baa8@github.com>
References: <3Ls58cgxNjNiZ7jjXlDYmTj-9b7hZl5bXaMZcozwWzE=.6fc146e0-d2e1-4ef1-936d-c6a278e0baa8@github.com>
Message-ID: <M5IE06-x28aoYA4ytia_4L8lJxYy_vpJN56otZkWSEk=.c51dbba7-a928-4f5d-86da-ef1d87798217@github.com>

On Mon, 1 Apr 2024 02:02:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the test failure reported in https://bugs.openjdk.org/browse/JDK-8328273?
> 
> As noted in that issue, the `sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java` intermittently fails with a port already in use error. The test attempts to find a free port and then uses it during the test. The interesting part is that the test already has a loop of 10 attempts to retry the test if the port wasn't actually free. So for the test to fail, it would then mean that each of the 10 attempts of using a free port failed (which should be extremely rare and should almost never happen). 
> 
> I didn't have an answer for that until today and had it on my TODO to look further. Credit goes to Kevin @kevinjwalls for identifying the issue - turns out this is the exact same issue that Kevin fixed in https://github.com/openjdk/jdk/pull/18470 for a different test. After noticing that fix, I spotted the same typo in the exception message check in this test. That explains why it wasn't retrying at most 10 times. The test was thus immediately failing on first attempt whenever the chosen free port was in use.
> 
> I have run this test with a test repeat of 50 with this change and the test now passes always. Without this change and a test repeat of 50, the test failed 2 times. I've additionally searched for any other similar typos in other tests and haven't found any (I searched for the string "Exception thrown by the agent :").

Thank you Dan for the review. 

Since this is a test-only trivial fix, I'll go ahead with the integration.

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

PR Comment: https://git.openjdk.org/jdk/pull/18561#issuecomment-2030898184

From jpai at openjdk.org  Tue Apr  2 01:17:04 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Apr 2024 01:17:04 GMT
Subject: Integrated: 8328273:
 sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java failed with
 java.rmi.server.ExportException: Port already in use
In-Reply-To: <3Ls58cgxNjNiZ7jjXlDYmTj-9b7hZl5bXaMZcozwWzE=.6fc146e0-d2e1-4ef1-936d-c6a278e0baa8@github.com>
References: <3Ls58cgxNjNiZ7jjXlDYmTj-9b7hZl5bXaMZcozwWzE=.6fc146e0-d2e1-4ef1-936d-c6a278e0baa8@github.com>
Message-ID: <wNaxTIHnaYdHnJnrHu63ZoYSwwaDk20vQ3230kF7saE=.043707de-d9ce-404d-b1b8-f70526e42c9a@github.com>

On Mon, 1 Apr 2024 02:02:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the test failure reported in https://bugs.openjdk.org/browse/JDK-8328273?
> 
> As noted in that issue, the `sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java` intermittently fails with a port already in use error. The test attempts to find a free port and then uses it during the test. The interesting part is that the test already has a loop of 10 attempts to retry the test if the port wasn't actually free. So for the test to fail, it would then mean that each of the 10 attempts of using a free port failed (which should be extremely rare and should almost never happen). 
> 
> I didn't have an answer for that until today and had it on my TODO to look further. Credit goes to Kevin @kevinjwalls for identifying the issue - turns out this is the exact same issue that Kevin fixed in https://github.com/openjdk/jdk/pull/18470 for a different test. After noticing that fix, I spotted the same typo in the exception message check in this test. That explains why it wasn't retrying at most 10 times. The test was thus immediately failing on first attempt whenever the chosen free port was in use.
> 
> I have run this test with a test repeat of 50 with this change and the test now passes always. Without this change and a test repeat of 50, the test failed 2 times. I've additionally searched for any other similar typos in other tests and haven't found any (I searched for the string "Exception thrown by the agent :").

This pull request has now been integrated.

Changeset: a85c8493
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a85c8493aec73e81c000ea3e3d983b05706bbfec
Stats:     4 lines in 2 files changed: 0 ins; 0 del; 4 mod

8328273: sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java failed with java.rmi.server.ExportException: Port already in use

Reviewed-by: dcubed

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

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

From dholmes at openjdk.org  Tue Apr  2 01:26:02 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 2 Apr 2024 01:26:02 GMT
Subject: RFR: 8318026: jcmd should provide access to detailed JVM object
 information [v11]
In-Reply-To: <dOvDzyHCw8sJixlFGHxhcBhG7ttmqB33pNo5WhIqnKk=.5f505681-d7de-48c4-909a-437852d2cc4d@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
 <dOvDzyHCw8sJixlFGHxhcBhG7ttmqB33pNo5WhIqnKk=.5f505681-d7de-48c4-909a-437852d2cc4d@github.com>
Message-ID: <TQuWBXOrirD7cybbTz87T5WnsVpJSz6NGA6SV-kbW8w=.1796e972-7bb9-4c08-b91e-8220d65b8c54@github.com>

On Wed, 27 Mar 2024 18:31:50 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Introduce the jcmd "VM.inspect" to implement access to detailed JVM object information.
>> 
>> Not recommended for live production use.  Requires UnlockDiagnosticVMOptions and not included in jcmd help output, to remind us this is not a general-purpose customer-facing tool.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test more pointer types: compiled method and metadata.

src/hotspot/share/services/diagnosticCommand.cpp line 1254:

> 1252:   DebuggingContext dc{}; // avoid asserts
> 1253: 
> 1254:   if (!UnlockDiagnosticVMOptions) {

Drive-by comment: As per the comment from @plummercj  this flag should not be hijacked for this purpose. If you need a VM flag to control this feature then please add one. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17655#discussion_r1547032078

From dholmes at openjdk.org  Tue Apr  2 02:05:03 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 2 Apr 2024 02:05:03 GMT
Subject: RFR: 8329103: assert(!thread->in_asgct()) failed during multi-mode
 profiling [v2]
In-Reply-To: <ezV9V76k6OLv895D1qR3sYkvgAwT1t_Tx5fJATLkhO0=.5e6d94c2-d067-4706-b7c7-1c752180692f@github.com>
References: <ZPdnCKuww5bXpaH68nF0V7C-27Fl4skdxhMno7Ol1CU=.bc054c41-6d8b-4fbf-a7a2-0ee56f7c4dd6@github.com>
 <ezV9V76k6OLv895D1qR3sYkvgAwT1t_Tx5fJATLkhO0=.5e6d94c2-d067-4706-b7c7-1c752180692f@github.com>
Message-ID: <zy0uHIvarizpaLu7ryfGvgMjI0wQwceY9jE-EyO7WPs=.90889b99-6490-4286-9250-e16f10b336a3@github.com>

On Fri, 29 Mar 2024 11:35:57 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> This fix makes `AsyncGetCallTrace` reentrant and async-signal-safe.
>> Reentrancy is required in the cases when two or more profiling engines are running at the same time, e.g., when CPU and Wall clock profilers work together and therefore one profiler may interrupt another in the middle of getting a stack trace.
>> 
>> Tested with async-profiler:
>> 
>> java -agentpath:/path/to/libasyncProfiler.so=start,event=cpu,interval=1ms,wall=1ms,file=profile.jfr
>
> Andrei Pangin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rephrased comment about AsyncGetCallTrace reentrancy

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18504#pullrequestreview-1972482922

From yyang at openjdk.org  Tue Apr  2 02:06:59 2024
From: yyang at openjdk.org (Yi Yang)
Date: Tue, 2 Apr 2024 02:06:59 GMT
Subject: RFR: JDK-8322042: HeapDumper should perform merge on the current
 thread instead of VMThread
In-Reply-To: <4--MamzddI0M3jpWu5NG1OvvX2aOo1vTUsH0TNYmty0=.9c4f04fc-2809-427f-9109-6a2f8be3ca5a@github.com>
References: <4--MamzddI0M3jpWu5NG1OvvX2aOo1vTUsH0TNYmty0=.9c4f04fc-2809-427f-9109-6a2f8be3ca5a@github.com>
Message-ID: <YznUHjqtZDxOZqKHm2B2W1Jo_MHGVy8UljnoaPKkco0=.aefb2e1f-5870-4e9b-b736-dff4841c4c0b@github.com>

On Tue, 2 Apr 2024 00:40:37 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updated HeapDumper to always perform merge on the current thread.
> 
> Testing: tier1-5, all HeapDump-related tests
>   Covered heap dumping scenarios:
>     - `jcmd GC.heap_dump` command;
>     - `HotSpotDiagnosticMXBean.dumpHeap()`;
>     - `HeapDumpBeforeFullGC`, `HeapDumpAfterFullGC` VM options;
>     - `HeapDumpOnOutOfMemoryError` VM option.

- jcmd GC.heap_dump command; `AttachListenerThread`
- HotSpotDiagnosticMXBean.dumpHeap(); `JavaThread`
- HeapDumpBeforeFullGC, HeapDumpAfterFullGC VM options; `VMThread`
- HeapDumpOnOutOfMemoryError VM option. `VMThread`
Mabye we can always use AttachListenerThread(via Handshake) or new virtual thread?

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

PR Review: https://git.openjdk.org/jdk/pull/18571#pullrequestreview-1972484174

From apangin at openjdk.org  Tue Apr  2 04:33:07 2024
From: apangin at openjdk.org (Andrei Pangin)
Date: Tue, 2 Apr 2024 04:33:07 GMT
Subject: Integrated: 8329103: assert(!thread->in_asgct()) failed during
 multi-mode profiling
In-Reply-To: <ZPdnCKuww5bXpaH68nF0V7C-27Fl4skdxhMno7Ol1CU=.bc054c41-6d8b-4fbf-a7a2-0ee56f7c4dd6@github.com>
References: <ZPdnCKuww5bXpaH68nF0V7C-27Fl4skdxhMno7Ol1CU=.bc054c41-6d8b-4fbf-a7a2-0ee56f7c4dd6@github.com>
Message-ID: <YrBQlztxluMYNRezsHNFhSE_xg7CkKBDI42cKMKf8zE=.9e283a64-d6f2-47a1-88f7-76163726fd4b@github.com>

On Wed, 27 Mar 2024 01:02:41 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

> This fix makes `AsyncGetCallTrace` reentrant and async-signal-safe.
> Reentrancy is required in the cases when two or more profiling engines are running at the same time, e.g., when CPU and Wall clock profilers work together and therefore one profiler may interrupt another in the middle of getting a stack trace.
> 
> Tested with async-profiler:
> 
> java -agentpath:/path/to/libasyncProfiler.so=start,event=cpu,interval=1ms,wall=1ms,file=profile.jfr

This pull request has now been integrated.

Changeset: 6b1b0e9d
Author:    Andrei Pangin <apangin at openjdk.org>
Committer: Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6b1b0e9d45eb56f88398e2a6bca0d90c03112eaa
Stats:     4 lines in 1 file changed: 2 ins; 0 del; 2 mod

8329103: assert(!thread->in_asgct()) failed during multi-mode profiling

Reviewed-by: dholmes, sspitsyn

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

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

From sspitsyn at openjdk.org  Tue Apr  2 08:19:03 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 2 Apr 2024 08:19:03 GMT
Subject: RFR: 8329491: GetThreadListStackTraces function should use
 JvmtiHandshake
Message-ID: <56L6f8XFyrB_cUSPTLWNIVhO0PU4w3PjRnpA5U7y_aI=.906bf099-af40-4192-a205-f84120e99ec8@github.com>

The internal JVM TI `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor the JVM TI function `GetThreadListStackTraces` on the base of `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes.

Testing:
 - Ran mach5 tiers 1-6

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

Commit messages:
 - 8329491: GetThreadListStackTraces function should use JvmtiHandshake

Changes: https://git.openjdk.org/jdk/pull/18574/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18574&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329491
  Stats: 42 lines in 3 files changed: 16 ins; 19 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/18574.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18574/head:pull/18574

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

From coleenp at openjdk.org  Tue Apr  2 12:18:59 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 2 Apr 2024 12:18:59 GMT
Subject: RFR: 8313332: Simplify lazy jmethodID cache in InstanceKlass
In-Reply-To: <OnCG3ISfuvt7bIZaKL5fV8PTaZe8KWs56IWc0XdeoYo=.9d61355a-a4fe-4f6c-9a12-805a9f1febc5@github.com>
References: <OnCG3ISfuvt7bIZaKL5fV8PTaZe8KWs56IWc0XdeoYo=.9d61355a-a4fe-4f6c-9a12-805a9f1febc5@github.com>
Message-ID: <outJfojUhsfXR9rLzRC8RCmmCrpeyV7_Bex7ZzhOXvE=.d0ac9015-c6e8-42ee-aa35-e9da365b989a@github.com>

On Fri, 29 Mar 2024 15:25:48 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change simplifies the code that grows the jmethodID cache in InstanceKlass.  Instead of lazily, when there's a rare request for a jmethodID for an obsolete method, the jmethodID cache is grown during the RedefineClasses safepoint.  The InstanceKlass's jmethodID cache is lazily allocated when there's a jmethodID allocated, so not every InstanceKlass has a cache, but the growth now only happens in a safepoint.  This code will become racy with the potential change for deallocating jmethodIDs.
> 
> Tested with tier1-4, vmTestbase/nsk/jvmti java/lang/instrument tests (in case they're not in tier1-4).

Thank you Alex!

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

PR Comment: https://git.openjdk.org/jdk/pull/18549#issuecomment-2031887624

From adinn at openjdk.org  Tue Apr  2 12:56:02 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 2 Apr 2024 12:56:02 GMT
Subject: RFR: 8318026: jcmd should provide access to detailed JVM object
 information [v9]
In-Reply-To: <Od6ytN_fIx6iqNjp1bB5cFUVCm4cXh0MBnmJddZflLk=.00d26c3b-6792-458d-9832-4971b90c3513@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
 <rGRHpEl5i0_QUufRwGakZIdspmZ8Qu8Z9VH49-R_5X4=.a391011d-46f7-4e91-913b-075e8c8ecd12@github.com>
 <FkpkXtC4BSEXGM0uCYWiroHZ4Y4MTdqhjfgb_AbCVOI=.ef819314-1dc5-4460-a807-400887fbeada@github.com>
 <Eh8mqo-MHczioKlpe_o_cvgpWZ9kminPmqNRkKPk0lA=.35465d6a-5668-4dbd-99c9-a43387b4915a@github.com>
 <Od6ytN_fIx6iqNjp1bB5cFUVCm4cXh0MBnmJddZflLk=.00d26c3b-6792-458d-9832-4971b90c3513@github.com>
Message-ID: <G8UYGaAfrgnY6ZmV04QeqNN14C7eG1kOhBdqptlczcU=.97765fda-e568-4522-9748-3a8c3cfa57c9@github.com>

On Thu, 28 Mar 2024 17:15:26 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>>> In my opinion, UnlockDiagnosticVMOptions is not a good enough safeguard since it guards a whole swathe of switches that we may instruct the customer to enable. Once enabled, my experience is that UnlockDiagnosticVMOptions often lingers around. It is not unusual for customer scenarios to have set +UnlockDiagnosticVMOptions because of some years ago support cases.
>> 
>> I think we also need to consider the flip side of this argument. Is this something that some customers might want to always enable, but don't want to always have UnlockDiagnosticVMOptions enabled. A new command line flag would be needed in that case.
>> 
>> Also, isn't UnlockDiagnosticVMOptions meant for enabling the use of diagnostic command line flags? Do we have examples of it enabling a hotspot feature that does not also require setting a diagnostic command line flag?
>
>> I think we also need to consider the flip side of this argument. Is this something that some customers might want to always enable, but don't want to always have UnlockDiagnosticVMOptions enabled. A new command line flag would be needed in that case.
>> 
>> Also, isn't UnlockDiagnosticVMOptions meant for enabling the use of diagnostic command line flags? Do we have examples of it enabling a hotspot feature that does not also require setting a diagnostic command line flag?
> 
> Thanks Chris - that is correct now I check the wording, UnlockDiagnosticVMOptions: "Enable normal processing of flags relating to field diagnostics"
> 
> Yes it makes flags which are DIAGNOSTIC available at the command-line.  We have UnlockExperimentalVMOptions also.
> 
> My original reason for the guard, is that the risk of fooling  the "good oop" check is that we could possibly crash (so that's answering your other question).  Inspecting an arbitrary pointer that looks enough like a Java heap object to fool the test, means it might try and resolve bad addresses for Klass pointer or field data.
> 
> I also have a stress test which examines every address in a Java heap to test for crashes.  That's obviously long-running as it does a jcmd for every iteration.  But I can't currently get a crash, trying G1, ZGC, ZGCGenerational.
> 
> Having a global guard to prevent usage of VM.inspect may be needed less than I thought, but will wait on the other thread before saying that is really the case.  We could have a new -XX flag to guard it (whether specific to this command or a more general UnlockDiagnosticFeatures.  I would definitely stick to this being in all builds, as we frequently "debug" non-debug builds.
> 
> Also, for your comment above about the new version of dbg_is_good_oop: this was added because although there are not many callers of it, I did not want to upset them.  During my earlier testing the detailed version of this method did upset something, although I cannot reproduce that today.  
> 
> I will rerun some tests on these items...

@kevinjwalls Thanks for clarifying the relevant behaviours and code paths as well as identifying a few places where documentation might help devs avoid tripping over any issues. Much appreciated.

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

PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-2031966028

From coleenp at openjdk.org  Tue Apr  2 13:23:16 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 2 Apr 2024 13:23:16 GMT
Subject: RFR: 8236736: Change notproduct JVM flags to develop flags
Message-ID: <25c1XDQrzxvG0AuxlRjQyznnTdLzD1-J4kebuXzj-Zc=.0f5d28e1-7672-40a9-97fe-04a77fda65d9@github.com>

Remove the notproduct distinction for command line options, rather than trying to wrestle the macros to fix the bug that they've been treated as develop options for some time now.  This simplifies the command line option macros.

Tested with tier1-4, tier1 on Oracle platforms.  Also built shenandoah.

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

Commit messages:
 - Missed one.
 - 8236736: Change notproduct JVM flags to develop flags

Changes: https://git.openjdk.org/jdk/pull/18541/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18541&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8236736
  Stats: 239 lines in 39 files changed: 1 ins; 89 del; 149 mod
  Patch: https://git.openjdk.org/jdk/pull/18541.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18541/head:pull/18541

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

From jpai at openjdk.org  Tue Apr  2 14:49:12 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Apr 2024 14:49:12 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v4]
In-Reply-To: <ap2euz_9D71i7sETBoE0v0XcvG6BLOhr-M-6lZ724mI=.43b029d0-afa5-4a9f-b5f3-d83d53859faf@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <ap2euz_9D71i7sETBoE0v0XcvG6BLOhr-M-6lZ724mI=.43b029d0-afa5-4a9f-b5f3-d83d53859faf@github.com>
Message-ID: <tqTfOs3OsGnGuNjeZSyKn94BHNFvqLtSx9ulVZceDJw=.09a55777-5bd4-49a7-a588-1595841c010a@github.com>

On Tue, 26 Mar 2024 18:18:39 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
>> 
>> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
>> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
>> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/nio/channels/unixdomain/Bind.java
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

test/jdk/java/nio/channels/unixdomain/NonBlockingAccept.java line 68:

> 66:             // or exception could be thrown otherwise
> 67:         } finally {
> 68:             Files.deleteIfExists(addr.getPath());

Hello Bill, `addr` can be `null` here, so this has a potential of a `NullPointerException`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1548038473

From jpai at openjdk.org  Tue Apr  2 14:56:01 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Apr 2024 14:56:01 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v4]
In-Reply-To: <ap2euz_9D71i7sETBoE0v0XcvG6BLOhr-M-6lZ724mI=.43b029d0-afa5-4a9f-b5f3-d83d53859faf@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <ap2euz_9D71i7sETBoE0v0XcvG6BLOhr-M-6lZ724mI=.43b029d0-afa5-4a9f-b5f3-d83d53859faf@github.com>
Message-ID: <hjGGd5cVG-hz1bHQi2Idj1sEPFmbGAPJtPe9c0B41OU=.057d651f-3341-47c9-94df-1102eaa32fbf@github.com>

On Tue, 26 Mar 2024 18:18:39 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
>> 
>> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
>> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
>> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/nio/channels/unixdomain/Bind.java
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

For the changes in `test/jdk/java/nio/file/Files/CheckPermissions.java` it would be good to have Alan and/or Brian's inputs. The test documentation says that the test relates to SecurityManager checks (and not filesystem permission checks), so the proposed changes in this PR to use a different parent directory for the temporary file(s) should be OK, but I am not familiar with that area to be certain about it.

test/jdk/sun/security/pkcs12/P12SecretKey.java line 69:

> 67: 
> 68:         File ksFile = File.createTempFile("test", ".test");
> 69:         ksFile.deleteOnExit();

Is there a reason why this change is done differently than the rest of the changes in this PR? Can we delete the `File` in a try/finally instead of enrolling a shutdown hook to delete it?

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

PR Comment: https://git.openjdk.org/jdk/pull/18352#issuecomment-2032269381
PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1548045308

From iklam at openjdk.org  Tue Apr  2 16:01:12 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 2 Apr 2024 16:01:12 GMT
Subject: RFR: 8236736: Change notproduct JVM flags to develop flags
In-Reply-To: <25c1XDQrzxvG0AuxlRjQyznnTdLzD1-J4kebuXzj-Zc=.0f5d28e1-7672-40a9-97fe-04a77fda65d9@github.com>
References: <25c1XDQrzxvG0AuxlRjQyznnTdLzD1-J4kebuXzj-Zc=.0f5d28e1-7672-40a9-97fe-04a77fda65d9@github.com>
Message-ID: <C_Ko3VfolSjPu5xrlr_7dXvRd4hYwHD_o0BsiOKOb2s=.7782e567-3f62-4ed3-be15-a975924e37fb@github.com>

On Thu, 28 Mar 2024 22:53:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Remove the notproduct distinction for command line options, rather than trying to wrestle the macros to fix the bug that they've been treated as develop options for some time now.  This simplifies the command line option macros.
> 
> Tested with tier1-4, tier1 on Oracle platforms.  Also built shenandoah.

LGTM.

For the past 15 years, "notproduct" flags haven't been working as they claim to be in globals.hpp. That doesn't seem to have bothered anyone. This definitely looks like a design that no one needs and should be removed for simplcity.

There are some references to "notproduct" in test/hotspot/jtreg/runtime/CommandLine that need to be removed.

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

Changes requested by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18541#pullrequestreview-1974267126

From coleenp at openjdk.org  Tue Apr  2 16:24:19 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 2 Apr 2024 16:24:19 GMT
Subject: RFR: 8236736: Change notproduct JVM flags to develop flags [v2]
In-Reply-To: <25c1XDQrzxvG0AuxlRjQyznnTdLzD1-J4kebuXzj-Zc=.0f5d28e1-7672-40a9-97fe-04a77fda65d9@github.com>
References: <25c1XDQrzxvG0AuxlRjQyznnTdLzD1-J4kebuXzj-Zc=.0f5d28e1-7672-40a9-97fe-04a77fda65d9@github.com>
Message-ID: <QgftUnVOGk6RVVe-HTPuzxmafkCtcKKenFRyseU-71g=.aaad76be-1e0b-4293-ae8e-9e046b614fe7@github.com>

> Remove the notproduct distinction for command line options, rather than trying to wrestle the macros to fix the bug that they've been treated as develop options for some time now.  This simplifies the command line option macros.
> 
> Tested with tier1-4, tier1 on Oracle platforms.  Also built shenandoah.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Clean up notproduct from tests.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18541/files
  - new: https://git.openjdk.org/jdk/pull/18541/files/c3d9a1c8..19b8f6b6

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

  Stats: 37 lines in 4 files changed: 0 ins; 8 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/18541.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18541/head:pull/18541

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

From iklam at openjdk.org  Tue Apr  2 16:24:19 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 2 Apr 2024 16:24:19 GMT
Subject: RFR: 8236736: Change notproduct JVM flags to develop flags [v2]
In-Reply-To: <QgftUnVOGk6RVVe-HTPuzxmafkCtcKKenFRyseU-71g=.aaad76be-1e0b-4293-ae8e-9e046b614fe7@github.com>
References: <25c1XDQrzxvG0AuxlRjQyznnTdLzD1-J4kebuXzj-Zc=.0f5d28e1-7672-40a9-97fe-04a77fda65d9@github.com>
 <QgftUnVOGk6RVVe-HTPuzxmafkCtcKKenFRyseU-71g=.aaad76be-1e0b-4293-ae8e-9e046b614fe7@github.com>
Message-ID: <cuFS3fdwlONF-rGc1InsnkE4GoGSwEx7E4jh0t1jzNY=.603eb76b-a10e-4831-bb87-02a8c8669165@github.com>

On Tue, 2 Apr 2024 16:21:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Remove the notproduct distinction for command line options, rather than trying to wrestle the macros to fix the bug that they've been treated as develop options for some time now.  This simplifies the command line option macros.
>> 
>> Tested with tier1-4, tier1 on Oracle platforms.  Also built shenandoah.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up notproduct from tests.

LGTM

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18541#pullrequestreview-1974322553

From coleenp at openjdk.org  Tue Apr  2 16:24:20 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 2 Apr 2024 16:24:20 GMT
Subject: RFR: 8236736: Change notproduct JVM flags to develop flags
In-Reply-To: <25c1XDQrzxvG0AuxlRjQyznnTdLzD1-J4kebuXzj-Zc=.0f5d28e1-7672-40a9-97fe-04a77fda65d9@github.com>
References: <25c1XDQrzxvG0AuxlRjQyznnTdLzD1-J4kebuXzj-Zc=.0f5d28e1-7672-40a9-97fe-04a77fda65d9@github.com>
Message-ID: <nPWRExv8E_LuD15xKu5pNVGHnWYl70fl82YKPOe7EmA=.c28d2bfe-c0ce-4d1b-b9d6-f9a3acfccbf4@github.com>

On Thu, 28 Mar 2024 22:53:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Remove the notproduct distinction for command line options, rather than trying to wrestle the macros to fix the bug that they've been treated as develop options for some time now.  This simplifies the command line option macros.
> 
> Tested with tier1-4, tier1 on Oracle platforms.  Also built shenandoah.

Thank you for pointing out that I missed cleaning up the tests.  One failed but I didn't see it.

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

PR Comment: https://git.openjdk.org/jdk/pull/18541#issuecomment-2032498785

From bhuang at openjdk.org  Tue Apr  2 16:29:21 2024
From: bhuang at openjdk.org (Bill Huang)
Date: Tue, 2 Apr 2024 16:29:21 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v5]
In-Reply-To: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
Message-ID: <OKHx2MPKdD8KfHo8DrMsVNIASU461yiCgH2_JB0A3CM=.6038dd44-085b-415f-970a-a33e3d6c29f0@github.com>

> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
> 
> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Implemented review comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18352/files
  - new: https://git.openjdk.org/jdk/pull/18352/files/0f4130a9..81244609

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

  Stats: 30 lines in 2 files changed: 12 ins; 5 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/18352.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18352/head:pull/18352

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

From stefank at openjdk.org  Tue Apr  2 16:59:13 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 2 Apr 2024 16:59:13 GMT
Subject: RFR: 8236736: Change notproduct JVM flags to develop flags [v2]
In-Reply-To: <QgftUnVOGk6RVVe-HTPuzxmafkCtcKKenFRyseU-71g=.aaad76be-1e0b-4293-ae8e-9e046b614fe7@github.com>
References: <25c1XDQrzxvG0AuxlRjQyznnTdLzD1-J4kebuXzj-Zc=.0f5d28e1-7672-40a9-97fe-04a77fda65d9@github.com>
 <QgftUnVOGk6RVVe-HTPuzxmafkCtcKKenFRyseU-71g=.aaad76be-1e0b-4293-ae8e-9e046b614fe7@github.com>
Message-ID: <fL1uGxDkFjBE0ZX5B6ms0995C9yl5AMrQ1z-DEHZuho=.c8e60fab-14cb-4eb4-8a85-aa2e2a1fab79@github.com>

On Tue, 2 Apr 2024 16:24:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Remove the notproduct distinction for command line options, rather than trying to wrestle the macros to fix the bug that they've been treated as develop options for some time now.  This simplifies the command line option macros.
>> 
>> Tested with tier1-4, tier1 on Oracle platforms.  Also built shenandoah.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up notproduct from tests.

src/hotspot/share/runtime/arguments.cpp line 3420:

> 3418: static void apply_debugger_ergo() {
> 3419: #ifndef PRODUCT
> 3420:   // UseDebuggerErgo is notproduct

Now that the flag has been changed to a develop flag, it seems wrong that these are guarded by "#ifndef PRODUCT". Shouldn't this be changed to check for ASSERT instead?

src/hotspot/share/runtime/flags/jvmFlag.hpp line 118:

> 116:     EXPERIMENTAL_FLAG_BUT_LOCKED,
> 117:     DEVELOPER_FLAG_BUT_PRODUCT_BUILD,
> 118:     NOTPRODUCT_FLAG_BUT_PRODUCT_BUILD

Should the ',' on the previous line be removed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18541#discussion_r1548236362
PR Review Comment: https://git.openjdk.org/jdk/pull/18541#discussion_r1548239130

From coleenp at openjdk.org  Tue Apr  2 17:16:01 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 2 Apr 2024 17:16:01 GMT
Subject: RFR: 8236736: Change notproduct JVM flags to develop flags [v2]
In-Reply-To: <QgftUnVOGk6RVVe-HTPuzxmafkCtcKKenFRyseU-71g=.aaad76be-1e0b-4293-ae8e-9e046b614fe7@github.com>
References: <25c1XDQrzxvG0AuxlRjQyznnTdLzD1-J4kebuXzj-Zc=.0f5d28e1-7672-40a9-97fe-04a77fda65d9@github.com>
 <QgftUnVOGk6RVVe-HTPuzxmafkCtcKKenFRyseU-71g=.aaad76be-1e0b-4293-ae8e-9e046b614fe7@github.com>
Message-ID: <1SplyimCOCzBkP_A15DW-Q_NcUg8d7qmrcNfBU3GJSk=.11aa3fa0-3e3d-4587-922c-ac89d984478d@github.com>

On Tue, 2 Apr 2024 16:24:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Remove the notproduct distinction for command line options, rather than trying to wrestle the macros to fix the bug that they've been treated as develop options for some time now.  This simplifies the command line option macros.
>> 
>> Tested with tier1-4, tier1 on Oracle platforms.  Also built shenandoah.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up notproduct from tests.

Thanks for looking through the changes, Stefan.

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

PR Review: https://git.openjdk.org/jdk/pull/18541#pullrequestreview-1974442423

From coleenp at openjdk.org  Tue Apr  2 17:16:02 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 2 Apr 2024 17:16:02 GMT
Subject: RFR: 8236736: Change notproduct JVM flags to develop flags [v2]
In-Reply-To: <fL1uGxDkFjBE0ZX5B6ms0995C9yl5AMrQ1z-DEHZuho=.c8e60fab-14cb-4eb4-8a85-aa2e2a1fab79@github.com>
References: <25c1XDQrzxvG0AuxlRjQyznnTdLzD1-J4kebuXzj-Zc=.0f5d28e1-7672-40a9-97fe-04a77fda65d9@github.com>
 <QgftUnVOGk6RVVe-HTPuzxmafkCtcKKenFRyseU-71g=.aaad76be-1e0b-4293-ae8e-9e046b614fe7@github.com>
 <fL1uGxDkFjBE0ZX5B6ms0995C9yl5AMrQ1z-DEHZuho=.c8e60fab-14cb-4eb4-8a85-aa2e2a1fab79@github.com>
Message-ID: <2XgKLmehivQ4frz5mofTSXn9LDFShIwprD6J2GUS_Is=.ecc3c80d-ea3f-447e-a951-9fbbb5c24a59@github.com>

On Tue, 2 Apr 2024 16:49:19 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clean up notproduct from tests.
>
> src/hotspot/share/runtime/arguments.cpp line 3420:
> 
>> 3418: static void apply_debugger_ergo() {
>> 3419: #ifndef PRODUCT
>> 3420:   // UseDebuggerErgo is notproduct
> 
> Now that the flag has been changed to a develop flag, it seems wrong that these are guarded by "#ifndef PRODUCT". Shouldn't this be changed to check for ASSERT instead?

Yes, ifdef ASSERT is more appropriate.

> src/hotspot/share/runtime/flags/jvmFlag.hpp line 118:
> 
>> 116:     EXPERIMENTAL_FLAG_BUT_LOCKED,
>> 117:     DEVELOPER_FLAG_BUT_PRODUCT_BUILD,
>> 118:     NOTPRODUCT_FLAG_BUT_PRODUCT_BUILD
> 
> Should the ',' on the previous line be removed?

Yes, I guess our compilers don't complain about that anymore.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18541#discussion_r1548261310
PR Review Comment: https://git.openjdk.org/jdk/pull/18541#discussion_r1548269993

From coleenp at openjdk.org  Tue Apr  2 17:25:12 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 2 Apr 2024 17:25:12 GMT
Subject: RFR: 8236736: Change notproduct JVM flags to develop flags [v3]
In-Reply-To: <25c1XDQrzxvG0AuxlRjQyznnTdLzD1-J4kebuXzj-Zc=.0f5d28e1-7672-40a9-97fe-04a77fda65d9@github.com>
References: <25c1XDQrzxvG0AuxlRjQyznnTdLzD1-J4kebuXzj-Zc=.0f5d28e1-7672-40a9-97fe-04a77fda65d9@github.com>
Message-ID: <jPjA4A6tDlOKKK-ui_6RJPQ4x5OIW_tL1AALv6YzW1E=.d161aa1a-de9e-445a-8a88-6d5c644d0880@github.com>

> Remove the notproduct distinction for command line options, rather than trying to wrestle the macros to fix the bug that they've been treated as develop options for some time now.  This simplifies the command line option macros.
> 
> Tested with tier1-4, tier1 on Oracle platforms.  Also built shenandoah.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix a couple issues pointed out by Stefank.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18541/files
  - new: https://git.openjdk.org/jdk/pull/18541/files/19b8f6b6..00a241d3

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

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

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

From kvn at openjdk.org  Tue Apr  2 17:37:10 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 2 Apr 2024 17:37:10 GMT
Subject: RFR: 8236736: Change notproduct JVM flags to develop flags [v3]
In-Reply-To: <jPjA4A6tDlOKKK-ui_6RJPQ4x5OIW_tL1AALv6YzW1E=.d161aa1a-de9e-445a-8a88-6d5c644d0880@github.com>
References: <25c1XDQrzxvG0AuxlRjQyznnTdLzD1-J4kebuXzj-Zc=.0f5d28e1-7672-40a9-97fe-04a77fda65d9@github.com>
 <jPjA4A6tDlOKKK-ui_6RJPQ4x5OIW_tL1AALv6YzW1E=.d161aa1a-de9e-445a-8a88-6d5c644d0880@github.com>
Message-ID: <lPip93C81Id4N8s8RQwpuFuVH67uyTpiqUMhWAYoeQs=.a56d49b4-bcaa-4d3a-99ce-10349df9c68b@github.com>

On Tue, 2 Apr 2024 17:25:12 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Remove the notproduct distinction for command line options, rather than trying to wrestle the macros to fix the bug that they've been treated as develop options for some time now.  This simplifies the command line option macros.
>> 
>> Tested with tier1-4, tier1 on Oracle platforms.  Also built shenandoah.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix a couple issues pointed out by Stefank.

So you finally decided to take on [JDK-8183288](https://bugs.openjdk.org/browse/JDK-8183288)

Essentially you are removing "optimized" VM build with these changes. In this case you need to change make files.

All Statistics flags should be product (which will increase product VM size) - it is important. May be need build's variable `--enable-jvm-feature-statistcs` to include statistics code on demand.

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

Changes requested by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18541#pullrequestreview-1974500625

From coleenp at openjdk.org  Tue Apr  2 18:01:10 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 2 Apr 2024 18:01:10 GMT
Subject: RFR: 8236736: Change notproduct JVM flags to develop flags [v3]
In-Reply-To: <jPjA4A6tDlOKKK-ui_6RJPQ4x5OIW_tL1AALv6YzW1E=.d161aa1a-de9e-445a-8a88-6d5c644d0880@github.com>
References: <25c1XDQrzxvG0AuxlRjQyznnTdLzD1-J4kebuXzj-Zc=.0f5d28e1-7672-40a9-97fe-04a77fda65d9@github.com>
 <jPjA4A6tDlOKKK-ui_6RJPQ4x5OIW_tL1AALv6YzW1E=.d161aa1a-de9e-445a-8a88-6d5c644d0880@github.com>
Message-ID: <QfTgke7CJrAB0F_IUfeEbuKBuVPk6b6VX3gfcWrn_Tg=.0a99e5dc-b5e4-4e6d-bd0a-b10e82bdb460@github.com>

On Tue, 2 Apr 2024 17:25:12 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Remove the notproduct distinction for command line options, rather than trying to wrestle the macros to fix the bug that they've been treated as develop options for some time now.  This simplifies the command line option macros.
>> 
>> Tested with tier1-4, tier1 on Oracle platforms.  Also built shenandoah.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix a couple issues pointed out by Stefank.

The optimized build still works as before (actually surprised it still builds). Since for a long time the notproduct options acted like develop options, they still do just the same for the optimized build.

For optimized, all the develop and notproduct options are materialized.   Now just develop, not distinguishing notproduct from that.  The same code enabled in PRODUCT is still enabled.  I haven't looked at that removing optimized bug in a while.

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

PR Comment: https://git.openjdk.org/jdk/pull/18541#issuecomment-2032704606

From kvn at openjdk.org  Tue Apr  2 18:42:02 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 2 Apr 2024 18:42:02 GMT
Subject: RFR: 8236736: Change notproduct JVM flags to develop flags [v3]
In-Reply-To: <jPjA4A6tDlOKKK-ui_6RJPQ4x5OIW_tL1AALv6YzW1E=.d161aa1a-de9e-445a-8a88-6d5c644d0880@github.com>
References: <25c1XDQrzxvG0AuxlRjQyznnTdLzD1-J4kebuXzj-Zc=.0f5d28e1-7672-40a9-97fe-04a77fda65d9@github.com>
 <jPjA4A6tDlOKKK-ui_6RJPQ4x5OIW_tL1AALv6YzW1E=.d161aa1a-de9e-445a-8a88-6d5c644d0880@github.com>
Message-ID: <pTHIYUU5KswvwIQoCAjLkqNOww0f6C_M3g78ubP-UoQ=.52462db6-335c-4569-8c64-d47a4fe25666@github.com>

On Tue, 2 Apr 2024 17:25:12 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Remove the notproduct distinction for command line options, rather than trying to wrestle the macros to fix the bug that they've been treated as develop options for some time now.  This simplifies the command line option macros.
>> 
>> Tested with tier1-4, tier1 on Oracle platforms.  Also built shenandoah.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix a couple issues pointed out by Stefank.

Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18541#pullrequestreview-1974635400

From kvn at openjdk.org  Tue Apr  2 18:42:02 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 2 Apr 2024 18:42:02 GMT
Subject: RFR: 8236736: Change notproduct JVM flags to develop flags [v3]
In-Reply-To: <QfTgke7CJrAB0F_IUfeEbuKBuVPk6b6VX3gfcWrn_Tg=.0a99e5dc-b5e4-4e6d-bd0a-b10e82bdb460@github.com>
References: <25c1XDQrzxvG0AuxlRjQyznnTdLzD1-J4kebuXzj-Zc=.0f5d28e1-7672-40a9-97fe-04a77fda65d9@github.com>
 <jPjA4A6tDlOKKK-ui_6RJPQ4x5OIW_tL1AALv6YzW1E=.d161aa1a-de9e-445a-8a88-6d5c644d0880@github.com>
 <QfTgke7CJrAB0F_IUfeEbuKBuVPk6b6VX3gfcWrn_Tg=.0a99e5dc-b5e4-4e6d-bd0a-b10e82bdb460@github.com>
Message-ID: <RRbjUV-p1gEfd4HXhepLmtrU7gCXuBHPj30SexzHehw=.3881fa59-7bab-4dc2-84fc-e6e879f18c45@github.com>

On Tue, 2 Apr 2024 17:58:47 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> For optimized, all the develop and notproduct options are materialized.

Okay, I see what you did here. You touched only flags declaration and did not `#ifndef PRODUCT` which guards statistics code, for example. Optimized VM build will get that code but will not include DEBUG_ONLY and `#ifdef ASSERT` guarded code.

So we still need to be careful when we use `#ifndef PRODUCT` and `#ifdef ASSERT`.

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

PR Comment: https://git.openjdk.org/jdk/pull/18541#issuecomment-2032789810

From coleenp at openjdk.org  Tue Apr  2 18:45:01 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 2 Apr 2024 18:45:01 GMT
Subject: RFR: 8236736: Change notproduct JVM flags to develop flags [v3]
In-Reply-To: <jPjA4A6tDlOKKK-ui_6RJPQ4x5OIW_tL1AALv6YzW1E=.d161aa1a-de9e-445a-8a88-6d5c644d0880@github.com>
References: <25c1XDQrzxvG0AuxlRjQyznnTdLzD1-J4kebuXzj-Zc=.0f5d28e1-7672-40a9-97fe-04a77fda65d9@github.com>
 <jPjA4A6tDlOKKK-ui_6RJPQ4x5OIW_tL1AALv6YzW1E=.d161aa1a-de9e-445a-8a88-6d5c644d0880@github.com>
Message-ID: <8j655T3fzB8EZT8JdQZMXPgArVeDOvkuY2n0Uwxz1Gk=.e5a2bf28-6ce2-49f2-95cd-f19f92b271df@github.com>

On Tue, 2 Apr 2024 17:25:12 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Remove the notproduct distinction for command line options, rather than trying to wrestle the macros to fix the bug that they've been treated as develop options for some time now.  This simplifies the command line option macros.
>> 
>> Tested with tier1-4, tier1 on Oracle platforms.  Also built shenandoah.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix a couple issues pointed out by Stefank.

Yes, I had to remember what optimized did.  It gets all the options, but builds with optimization and doesn't turn on asserts.  I only removed the notproduct flag distinction since it hasn't been distinct for years and it's confusing what we actually wanted it to do.

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

PR Comment: https://git.openjdk.org/jdk/pull/18541#issuecomment-2032794955

From kvn at openjdk.org  Tue Apr  2 19:02:10 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 2 Apr 2024 19:02:10 GMT
Subject: RFR: 8236736: Change notproduct JVM flags to develop flags [v3]
In-Reply-To: <jPjA4A6tDlOKKK-ui_6RJPQ4x5OIW_tL1AALv6YzW1E=.d161aa1a-de9e-445a-8a88-6d5c644d0880@github.com>
References: <25c1XDQrzxvG0AuxlRjQyznnTdLzD1-J4kebuXzj-Zc=.0f5d28e1-7672-40a9-97fe-04a77fda65d9@github.com>
 <jPjA4A6tDlOKKK-ui_6RJPQ4x5OIW_tL1AALv6YzW1E=.d161aa1a-de9e-445a-8a88-6d5c644d0880@github.com>
Message-ID: <QRE7Qh5c_GGflvWZaVCfp3AxSY4DjCtk4q_JwVsaOCc=.e4af2999-b4e8-4ad1-baca-7600fced3689@github.com>

On Tue, 2 Apr 2024 17:25:12 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Remove the notproduct distinction for command line options, rather than trying to wrestle the macros to fix the bug that they've been treated as develop options for some time now.  This simplifies the command line option macros.
>> 
>> Tested with tier1-4, tier1 on Oracle platforms.  Also built shenandoah.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix a couple issues pointed out by Stefank.

Long ago, before [JDK-8024545](https://bugs.openjdk.org/browse/JDK-8024545) we did not have not_product flags declared in product build. Only debug flags were declared as constant. We relied on that change since then.
That is why you may see the issue with not materialized flags in product build.

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

PR Comment: https://git.openjdk.org/jdk/pull/18541#issuecomment-2032835463

From kbarrett at openjdk.org  Tue Apr  2 19:08:01 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 2 Apr 2024 19:08:01 GMT
Subject: RFR: 8236736: Change notproduct JVM flags to develop flags [v3]
In-Reply-To: <jPjA4A6tDlOKKK-ui_6RJPQ4x5OIW_tL1AALv6YzW1E=.d161aa1a-de9e-445a-8a88-6d5c644d0880@github.com>
References: <25c1XDQrzxvG0AuxlRjQyznnTdLzD1-J4kebuXzj-Zc=.0f5d28e1-7672-40a9-97fe-04a77fda65d9@github.com>
 <jPjA4A6tDlOKKK-ui_6RJPQ4x5OIW_tL1AALv6YzW1E=.d161aa1a-de9e-445a-8a88-6d5c644d0880@github.com>
Message-ID: <-Di8CpUXEjVtG3uu2r_djrEuUDpnQF833TWGkDHmZM4=.176b6bd0-e84d-40f1-999e-4fe41c750d8a@github.com>

On Tue, 2 Apr 2024 17:25:12 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Remove the notproduct distinction for command line options, rather than trying to wrestle the macros to fix the bug that they've been treated as develop options for some time now.  This simplifies the command line option macros.
>> 
>> Tested with tier1-4, tier1 on Oracle platforms.  Also built shenandoah.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix a couple issues pointed out by Stefank.

Looks good.  One minor nit.

Also, it seems that develop and nonproduct (before this change) flags have
associated JVMFlag objects even in product builds. (The function
JVMFlag::is_constant_in_binary is evidence for this. I didn't dig through all
the code to verify it.) Probably if one were going to retain nonproduct
options and make them work "properly", they would only have JVMFlag objects in
non-product builds. But it's not obvious to me why we would want such objects
for either category in product builds. I think any change along that line
should be a separate followup.

test/hotspot/jtreg/runtime/CommandLine/VMOptionWarning.java line 64:

> 62:         output = new OutputAnalyzer(pb.start());
> 63:         output.shouldNotHaveExitValue(0);
> 64:         output.shouldContain("Error: VM option 'CheckCompressedOops' is develop and is available only in debug version of VM.");

Seems like we don't need this test of the develop option CheckCompressedOops at all, since we have
the immediately preceding test of the develop option VerifyStack.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18541#pullrequestreview-1974549362
PR Review Comment: https://git.openjdk.org/jdk/pull/18541#discussion_r1548328730

From coleenp at openjdk.org  Tue Apr  2 19:16:00 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 2 Apr 2024 19:16:00 GMT
Subject: RFR: JDK-8328137: PreserveAllAnnotations can cause failure of
 class retransformation
In-Reply-To: <eDd0gtG7NpbrXcM3zqdfYxJX91EDDa3qOl6DN60tMVw=.240ea2e6-9533-4980-9074-497fce7f00ce@github.com>
References: <eDd0gtG7NpbrXcM3zqdfYxJX91EDDa3qOl6DN60tMVw=.240ea2e6-9533-4980-9074-497fce7f00ce@github.com>
Message-ID: <oqGiYxyaZPy-jSjMZyOyFJ6Jx8zpA4ryyrMQry-1auo=.49b0b9a1-684f-449a-9498-02c7ba1cb67b@github.com>

On Thu, 28 Mar 2024 22:12:49 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> PreserveAllAnnotations option causes class file parser to preserve RuntimeInvisibleAnnotations so VM considers them as RuntimeVisibleAnnotations.
> For class retransformation JvmtiClassFileReconstituter restores all annotations as RuntimeVisibleAnnotations attributes.
> This can cause problem is the class contains only RuntimeInvisibleAnnotations, so corresponding RuntimeVisibleAnnotations attribute name is not present in the class constant pool.
> 
> Correct solution would be to store additional information about RuntimeInvisibleAnnotations and restore them exactly as they were in the original class (this should be done for all annotations: RuntimeInvisibleAnnotations/RuntimeInvisibleTypeAnnotations for class, fields and records, RuntimeInvisibleAnnotations/RuntimeInvisibleTypeAnnotations/RuntimeInvisibleParameterAnnotations for methods; need to ensure the information is correctly updated during class redefinition & retransformation).
> 
> I think it doesn't make sense to add all the complexity for almost no value (I doubt anyone uses PreserveAllAnnotations, the flag looks like experimental, we don't have any tests for it).
> 
> The suggested fix adds workaround for this corner case - if "visible" attribute name is not in the CP, the annotations are restored with "invisible" attribute name.
> 
> Testing:
>   - tier1,tier2,hs-tier5-svc
>   - all java/lang/instrument tests;
>   - all RedefineClasses/RetransformClasses tests

At one point long ago, I was trying to understand why we have PreserveAllAnnotations and couldn't come up with a reason.  For a class file reconstitutor, restoring the invisible annotations to the classfile and then feeding it back to the JVM should have no effect, since the VM doesn't do anything with these annotations.

I see now why you get the original assert.   I think this looks like a reasonable workaround for this problem.

I wonder if we can deprecate PreserveAllAnnotations.  Wonder what it's for?  It would need a CSR because it's a product flag.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18540#pullrequestreview-1974754738

From coleenp at openjdk.org  Tue Apr  2 19:29:09 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 2 Apr 2024 19:29:09 GMT
Subject: RFR: 8236736: Change notproduct JVM flags to develop flags [v3]
In-Reply-To: <-Di8CpUXEjVtG3uu2r_djrEuUDpnQF833TWGkDHmZM4=.176b6bd0-e84d-40f1-999e-4fe41c750d8a@github.com>
References: <25c1XDQrzxvG0AuxlRjQyznnTdLzD1-J4kebuXzj-Zc=.0f5d28e1-7672-40a9-97fe-04a77fda65d9@github.com>
 <jPjA4A6tDlOKKK-ui_6RJPQ4x5OIW_tL1AALv6YzW1E=.d161aa1a-de9e-445a-8a88-6d5c644d0880@github.com>
 <-Di8CpUXEjVtG3uu2r_djrEuUDpnQF833TWGkDHmZM4=.176b6bd0-e84d-40f1-999e-4fe41c750d8a@github.com>
Message-ID: <Ko1s3hmbLgDu5ulMH5WJCv8B49-uBsLUjcvmEO7jPZE=.8e7d2fa7-f830-4f6c-81ea-3f89122cddce@github.com>

On Tue, 2 Apr 2024 17:58:16 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix a couple issues pointed out by Stefank.
>
> test/hotspot/jtreg/runtime/CommandLine/VMOptionWarning.java line 64:
> 
>> 62:         output = new OutputAnalyzer(pb.start());
>> 63:         output.shouldNotHaveExitValue(0);
>> 64:         output.shouldContain("Error: VM option 'CheckCompressedOops' is develop and is available only in debug version of VM.");
> 
> Seems like we don't need this test of the develop option CheckCompressedOops at all, since we have
> the immediately preceding test of the develop option VerifyStack.

You're right, we've already tested this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18541#discussion_r1548488160

From coleenp at openjdk.org  Tue Apr  2 19:47:23 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 2 Apr 2024 19:47:23 GMT
Subject: RFR: 8236736: Change notproduct JVM flags to develop flags [v4]
In-Reply-To: <25c1XDQrzxvG0AuxlRjQyznnTdLzD1-J4kebuXzj-Zc=.0f5d28e1-7672-40a9-97fe-04a77fda65d9@github.com>
References: <25c1XDQrzxvG0AuxlRjQyznnTdLzD1-J4kebuXzj-Zc=.0f5d28e1-7672-40a9-97fe-04a77fda65d9@github.com>
Message-ID: <vD-L2x7FsbI73-fnKI9gis14awM8xL-IPeXzDfMYUqE=.c5c01067-f446-4538-8b66-b522a3cdbd2f@github.com>

> Remove the notproduct distinction for command line options, rather than trying to wrestle the macros to fix the bug that they've been treated as develop options for some time now.  This simplifies the command line option macros.
> 
> Tested with tier1-4, tier1 on Oracle platforms.  Also built shenandoah.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Remove redundant test case.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18541/files
  - new: https://git.openjdk.org/jdk/pull/18541/files/00a241d3..3b5002d8

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

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

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

From coleenp at openjdk.org  Tue Apr  2 19:54:01 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 2 Apr 2024 19:54:01 GMT
Subject: RFR: 8236736: Change notproduct JVM flags to develop flags [v4]
In-Reply-To: <vD-L2x7FsbI73-fnKI9gis14awM8xL-IPeXzDfMYUqE=.c5c01067-f446-4538-8b66-b522a3cdbd2f@github.com>
References: <25c1XDQrzxvG0AuxlRjQyznnTdLzD1-J4kebuXzj-Zc=.0f5d28e1-7672-40a9-97fe-04a77fda65d9@github.com>
 <vD-L2x7FsbI73-fnKI9gis14awM8xL-IPeXzDfMYUqE=.c5c01067-f446-4538-8b66-b522a3cdbd2f@github.com>
Message-ID: <8dFwjhziEAnv-PG3YM6FuPLbB6HlyO4BApqmuLwc3xo=.cf4ae09a-cf37-4f30-bcad-1f0582de82d1@github.com>

On Tue, 2 Apr 2024 19:47:23 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Remove the notproduct distinction for command line options, rather than trying to wrestle the macros to fix the bug that they've been treated as develop options for some time now.  This simplifies the command line option macros.
>> 
>> Tested with tier1-4, tier1 on Oracle platforms.  Also built shenandoah.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant test case.

Thanks for reviewing, Kim.  Is your suggestion to not have a JVMFlag object for develop flags in PRODUCT builds? Presumably to save some footprint?  I'm not sure we would win fighting the macros to accomplish this.

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

PR Comment: https://git.openjdk.org/jdk/pull/18541#issuecomment-2032981431

From kbarrett at openjdk.org  Tue Apr  2 20:21:11 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 2 Apr 2024 20:21:11 GMT
Subject: RFR: 8236736: Change notproduct JVM flags to develop flags [v4]
In-Reply-To: <8dFwjhziEAnv-PG3YM6FuPLbB6HlyO4BApqmuLwc3xo=.cf4ae09a-cf37-4f30-bcad-1f0582de82d1@github.com>
References: <25c1XDQrzxvG0AuxlRjQyznnTdLzD1-J4kebuXzj-Zc=.0f5d28e1-7672-40a9-97fe-04a77fda65d9@github.com>
 <vD-L2x7FsbI73-fnKI9gis14awM8xL-IPeXzDfMYUqE=.c5c01067-f446-4538-8b66-b522a3cdbd2f@github.com>
 <8dFwjhziEAnv-PG3YM6FuPLbB6HlyO4BApqmuLwc3xo=.cf4ae09a-cf37-4f30-bcad-1f0582de82d1@github.com>
Message-ID: <uMoZjOdPh_ay7jJL9cMQDEF8xTL0YtkZv4quW9Kn7zk=.9767c201-4b36-49fe-ba37-7c471c2f93fe@github.com>

On Tue, 2 Apr 2024 19:51:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Thanks for reviewing, Kim. Is your suggestion to not have a JVMFlag object for develop flags in PRODUCT builds? Presumably to save some footprint? I'm not sure we would win fighting the macros to accomplish this.

Yes, that's the suggestion and the rationale for it.  It should also remove the need for is_constant_in_binary.  I don't
know how hard it would actually be to accomplish this.  I agree it might not be worth the effort, but we won't know
until someone looks, which I haven't done.  It might even be easy.

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

PR Comment: https://git.openjdk.org/jdk/pull/18541#issuecomment-2033020865

From sspitsyn at openjdk.org  Tue Apr  2 20:38:08 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 2 Apr 2024 20:38:08 GMT
Subject: RFR: JDK-8328137: PreserveAllAnnotations can cause failure of
 class retransformation
In-Reply-To: <eDd0gtG7NpbrXcM3zqdfYxJX91EDDa3qOl6DN60tMVw=.240ea2e6-9533-4980-9074-497fce7f00ce@github.com>
References: <eDd0gtG7NpbrXcM3zqdfYxJX91EDDa3qOl6DN60tMVw=.240ea2e6-9533-4980-9074-497fce7f00ce@github.com>
Message-ID: <42DQj6IN0P_snFDH2haNpi-IxQVlx1tkL-i4IRIsVi0=.acb160f2-d26e-4c3c-a46a-620dd4a8c728@github.com>

On Thu, 28 Mar 2024 22:12:49 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> PreserveAllAnnotations option causes class file parser to preserve RuntimeInvisibleAnnotations so VM considers them as RuntimeVisibleAnnotations.
> For class retransformation JvmtiClassFileReconstituter restores all annotations as RuntimeVisibleAnnotations attributes.
> This can cause problem is the class contains only RuntimeInvisibleAnnotations, so corresponding RuntimeVisibleAnnotations attribute name is not present in the class constant pool.
> 
> Correct solution would be to store additional information about RuntimeInvisibleAnnotations and restore them exactly as they were in the original class (this should be done for all annotations: RuntimeInvisibleAnnotations/RuntimeInvisibleTypeAnnotations for class, fields and records, RuntimeInvisibleAnnotations/RuntimeInvisibleTypeAnnotations/RuntimeInvisibleParameterAnnotations for methods; need to ensure the information is correctly updated during class redefinition & retransformation).
> 
> I think it doesn't make sense to add all the complexity for almost no value (I doubt anyone uses PreserveAllAnnotations, the flag looks like experimental, we don't have any tests for it).
> 
> The suggested fix adds workaround for this corner case - if "visible" attribute name is not in the CP, the annotations are restored with "invisible" attribute name.
> 
> Testing:
>   - tier1,tier2,hs-tier5-svc
>   - all java/lang/instrument tests;
>   - all RedefineClasses/RetransformClasses tests

Looks good.
Sorry for delay. I thought I've already approved it. :(

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18540#pullrequestreview-1974973529

From sspitsyn at openjdk.org  Tue Apr  2 20:47:08 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 2 Apr 2024 20:47:08 GMT
Subject: RFR: JDK-8322042: HeapDumper should perform merge on the current
 thread instead of VMThread
In-Reply-To: <4--MamzddI0M3jpWu5NG1OvvX2aOo1vTUsH0TNYmty0=.9c4f04fc-2809-427f-9109-6a2f8be3ca5a@github.com>
References: <4--MamzddI0M3jpWu5NG1OvvX2aOo1vTUsH0TNYmty0=.9c4f04fc-2809-427f-9109-6a2f8be3ca5a@github.com>
Message-ID: <Zt5--8aNl3mT1Dte2lIJI1sVFQKiaWcpfIOv1QwugaY=.e4ee84d7-47aa-4902-bd14-2527cd026564@github.com>

On Tue, 2 Apr 2024 00:40:37 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updated HeapDumper to always perform merge on the current thread.
> 
> Testing: tier1-5, all HeapDump-related tests
>   Covered heap dumping scenarios:
>     - `jcmd GC.heap_dump` command;
>     - `HotSpotDiagnosticMXBean.dumpHeap()`;
>     - `HeapDumpBeforeFullGC`, `HeapDumpAfterFullGC` VM options;
>     - `HeapDumpOnOutOfMemoryError` VM option.

Marked as reviewed by sspitsyn (Reviewer).

This looks good and simpler to me.

src/hotspot/share/services/heapDumper.cpp line 2648:

> 2646: 
> 2647:   DumpMerger merger(path, &writer, dumper.dump_seq());
> 2648:   // perform heapdump file merge operation in the current thread prevents us

Nit: Better to start with a capital letter.

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

PR Review: https://git.openjdk.org/jdk/pull/18571#pullrequestreview-1974986347
PR Comment: https://git.openjdk.org/jdk/pull/18571#issuecomment-2033059611
PR Review Comment: https://git.openjdk.org/jdk/pull/18571#discussion_r1548582212

From amenkov at openjdk.org  Tue Apr  2 21:13:33 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 2 Apr 2024 21:13:33 GMT
Subject: RFR: JDK-8322042: HeapDumper should perform merge on the current
 thread instead of VMThread [v2]
In-Reply-To: <4--MamzddI0M3jpWu5NG1OvvX2aOo1vTUsH0TNYmty0=.9c4f04fc-2809-427f-9109-6a2f8be3ca5a@github.com>
References: <4--MamzddI0M3jpWu5NG1OvvX2aOo1vTUsH0TNYmty0=.9c4f04fc-2809-427f-9109-6a2f8be3ca5a@github.com>
Message-ID: <5DSzGDsLSswF0y1iWTfoq0kYpZqXPqVLgN4lItTF1EE=.2989a521-e453-41fb-89e8-3aabe478f8a8@github.com>

> The fix updated HeapDumper to always perform merge on the current thread.
> 
> Testing: tier1-5, all HeapDump-related tests
>   Covered heap dumping scenarios:
>     - `jcmd GC.heap_dump` command;
>     - `HotSpotDiagnosticMXBean.dumpHeap()`;
>     - `HeapDumpBeforeFullGC`, `HeapDumpAfterFullGC` VM options;
>     - `HeapDumpOnOutOfMemoryError` VM option.

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18571/files
  - new: https://git.openjdk.org/jdk/pull/18571/files/e373d793..2eb802f7

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

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

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

From amenkov at openjdk.org  Tue Apr  2 21:13:33 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 2 Apr 2024 21:13:33 GMT
Subject: RFR: JDK-8322042: HeapDumper should perform merge on the current
 thread instead of VMThread [v2]
In-Reply-To: <YznUHjqtZDxOZqKHm2B2W1Jo_MHGVy8UljnoaPKkco0=.aefb2e1f-5870-4e9b-b736-dff4841c4c0b@github.com>
References: <4--MamzddI0M3jpWu5NG1OvvX2aOo1vTUsH0TNYmty0=.9c4f04fc-2809-427f-9109-6a2f8be3ca5a@github.com>
 <YznUHjqtZDxOZqKHm2B2W1Jo_MHGVy8UljnoaPKkco0=.aefb2e1f-5870-4e9b-b736-dff4841c4c0b@github.com>
Message-ID: <YbWTTSGzxoDh7o0lHbwCII7oqiJLrVslIoeT-J0flfM=.37bd2889-376e-431d-81a0-7f3c4fd7d22d@github.com>

On Tue, 2 Apr 2024 02:04:17 GMT, Yi Yang <yyang at openjdk.org> wrote:

> * jcmd GC.heap_dump command; `AttachListenerThread`
> 
>     * HotSpotDiagnosticMXBean.dumpHeap(); `JavaThread`
> 
>     * HeapDumpBeforeFullGC, HeapDumpAfterFullGC VM options; `VMThread`
> 
>     * HeapDumpOnOutOfMemoryError VM option. `VMThread`
>       Mabye we can always use AttachListenerThread(via Handshake) or new virtual thread?

AttachListenerThread may not exist (it's created on demand).
Heap dump for HeapDumpOnOutOfMemoryError is performed on the current java thread.
I'm not sure I follow the proposal. What if the profit in using separate thread for merging?

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

PR Comment: https://git.openjdk.org/jdk/pull/18571#issuecomment-2033101158

From amenkov at openjdk.org  Tue Apr  2 21:40:10 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 2 Apr 2024 21:40:10 GMT
Subject: RFR: JDK-8322042: HeapDumper should perform merge on the current
 thread instead of VMThread [v2]
In-Reply-To: <Zt5--8aNl3mT1Dte2lIJI1sVFQKiaWcpfIOv1QwugaY=.e4ee84d7-47aa-4902-bd14-2527cd026564@github.com>
References: <4--MamzddI0M3jpWu5NG1OvvX2aOo1vTUsH0TNYmty0=.9c4f04fc-2809-427f-9109-6a2f8be3ca5a@github.com>
 <Zt5--8aNl3mT1Dte2lIJI1sVFQKiaWcpfIOv1QwugaY=.e4ee84d7-47aa-4902-bd14-2527cd026564@github.com>
Message-ID: <DaRJw4Ldb9Ug5lLUsHKWmQ_HgwAla2DaQeo2EilCMb8=.c0ba54b8-760d-40e3-b043-27508417c984@github.com>

On Tue, 2 Apr 2024 20:44:13 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comment
>
> src/hotspot/share/services/heapDumper.cpp line 2648:
> 
>> 2646: 
>> 2647:   DumpMerger merger(path, &writer, dumper.dump_seq());
>> 2648:   // perform heapdump file merge operation in the current thread prevents us
> 
> Nit: Better to start with a capital letter.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18571#discussion_r1548639189

From iklam at openjdk.org  Tue Apr  2 22:08:10 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 2 Apr 2024 22:08:10 GMT
Subject: RFR: 8236736: Change notproduct JVM flags to develop flags [v4]
In-Reply-To: <uMoZjOdPh_ay7jJL9cMQDEF8xTL0YtkZv4quW9Kn7zk=.9767c201-4b36-49fe-ba37-7c471c2f93fe@github.com>
References: <25c1XDQrzxvG0AuxlRjQyznnTdLzD1-J4kebuXzj-Zc=.0f5d28e1-7672-40a9-97fe-04a77fda65d9@github.com>
 <vD-L2x7FsbI73-fnKI9gis14awM8xL-IPeXzDfMYUqE=.c5c01067-f446-4538-8b66-b522a3cdbd2f@github.com>
 <8dFwjhziEAnv-PG3YM6FuPLbB6HlyO4BApqmuLwc3xo=.cf4ae09a-cf37-4f30-bcad-1f0582de82d1@github.com>
 <uMoZjOdPh_ay7jJL9cMQDEF8xTL0YtkZv4quW9Kn7zk=.9767c201-4b36-49fe-ba37-7c471c2f93fe@github.com>
Message-ID: <JcPhv31s2Uow_HF2dpnUDrDeqxFwRu7sfVTKOpAbxXo=.47cfa929-9f85-4fa4-aa0b-7e0f74bc6139@github.com>

On Tue, 2 Apr 2024 20:18:34 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> > Thanks for reviewing, Kim. Is your suggestion to not have a JVMFlag object for develop flags in PRODUCT builds? Presumably to save some footprint? I'm not sure we would win fighting the macros to accomplish this.
> 
> Yes, that's the suggestion and the rationale for it. It should also remove the need for is_constant_in_binary. I don't know how hard it would actually be to accomplish this. I agree it might not be worth the effort, but we won't know until someone looks, which I haven't done. It might even be easy.

Currently the VM prints an error message for non-product flags, so we need to keep some information about them. We can probably skip the type information, etc, to save a little space, but the space saving would be minimal.


$ java -XX:+LoomDeoptAfterThaw --version
Error: VM option 'LoomDeoptAfterThaw' is develop and is available only in debug version of VM.
Improperly specified VM option 'LoomDeoptAfterThaw'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

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

PR Comment: https://git.openjdk.org/jdk/pull/18541#issuecomment-2033183718

From pchilanomate at openjdk.org  Tue Apr  2 22:24:08 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 2 Apr 2024 22:24:08 GMT
Subject: RFR: 8329491: GetThreadListStackTraces function should use
 JvmtiHandshake
In-Reply-To: <56L6f8XFyrB_cUSPTLWNIVhO0PU4w3PjRnpA5U7y_aI=.906bf099-af40-4192-a205-f84120e99ec8@github.com>
References: <56L6f8XFyrB_cUSPTLWNIVhO0PU4w3PjRnpA5U7y_aI=.906bf099-af40-4192-a205-f84120e99ec8@github.com>
Message-ID: <pn6v4lWYZ_hFamtaLY3dXbpC5mfE6WxK7tmfLvhnZfo=.32a3695c-abc8-4eec-9d6b-47ae0cffc50a@github.com>

On Tue, 2 Apr 2024 08:13:20 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The internal JVM TI `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor the JVM TI function `GetThreadListStackTraces` on the base of `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes.
> 
> Testing:
>  - Ran mach5 tiers 1-6

Looks good to me.

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

> 1984:   jvmtiError err = JvmtiEnvBase::get_threadOop_and_JavaThread(tlh.list(), target, &java_thread, &thread_obj);
> 1985:   if (err != JVMTI_ERROR_NONE) {
> 1986:     printf("DBG: JvmtiHandshake::execute: err: %d\n", (int)err); fflush(0);

Any reason why not use UL instead with jvmti tag?

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

Marked as reviewed by pchilanomate (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18574#pullrequestreview-1975169550
PR Review Comment: https://git.openjdk.org/jdk/pull/18574#discussion_r1548686478

From pchilanomate at openjdk.org  Tue Apr  2 22:48:03 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 2 Apr 2024 22:48:03 GMT
Subject: RFR: 8329432: PopFrame and ForceEarlyReturn functions should use
 JvmtiHandshake
In-Reply-To: <5tcPHZX0nNTHbQqZfHRl2riTpJglQyGJ2hRJXyIMZPY=.4de7ac6d-dd84-4943-bab1-5dba67bf5cf0@github.com>
References: <5tcPHZX0nNTHbQqZfHRl2riTpJglQyGJ2hRJXyIMZPY=.4de7ac6d-dd84-4943-bab1-5dba67bf5cf0@github.com>
Message-ID: <vRd7mWgx-QXdmH41zKQUW6tuTXaJj5FAPEWPjCvz-78=.022750d7-801c-4271-b03e-3bb768005b12@github.com>

On Tue, 2 Apr 2024 00:22:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The internal JVM TI `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor JVM TI functions `PopFrame` and `ForceEarlyReturn` on the base of `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes.
> 
> Testing:
> 
>     Ran mach5 tiers 1-6

Looks good to me.

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

Marked as reviewed by pchilanomate (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18570#pullrequestreview-1975197001

From sspitsyn at openjdk.org  Tue Apr  2 23:52:33 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 2 Apr 2024 23:52:33 GMT
Subject: RFR: 8329491: GetThreadListStackTraces function should use
 JvmtiHandshake [v2]
In-Reply-To: <56L6f8XFyrB_cUSPTLWNIVhO0PU4w3PjRnpA5U7y_aI=.906bf099-af40-4192-a205-f84120e99ec8@github.com>
References: <56L6f8XFyrB_cUSPTLWNIVhO0PU4w3PjRnpA5U7y_aI=.906bf099-af40-4192-a205-f84120e99ec8@github.com>
Message-ID: <trwON1_yCYEqtpVxhkGJQJ2rMA7woYCInkqZ1GO1xKc=.3043e002-6d4a-4485-91f7-915515c65df9@github.com>

> The internal JVM TI `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor the JVM TI function `GetThreadListStackTraces` on the base of `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes.
> 
> Testing:
>  - Ran mach5 tiers 1-6

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

  review: cleanup - removed temporary logging used for debugging

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18574/files
  - new: https://git.openjdk.org/jdk/pull/18574/files/86cb34e7..8f048d34

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

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

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

From sspitsyn at openjdk.org  Wed Apr  3 00:00:11 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 3 Apr 2024 00:00:11 GMT
Subject: RFR: 8329491: GetThreadListStackTraces function should use
 JvmtiHandshake [v2]
In-Reply-To: <trwON1_yCYEqtpVxhkGJQJ2rMA7woYCInkqZ1GO1xKc=.3043e002-6d4a-4485-91f7-915515c65df9@github.com>
References: <56L6f8XFyrB_cUSPTLWNIVhO0PU4w3PjRnpA5U7y_aI=.906bf099-af40-4192-a205-f84120e99ec8@github.com>
 <trwON1_yCYEqtpVxhkGJQJ2rMA7woYCInkqZ1GO1xKc=.3043e002-6d4a-4485-91f7-915515c65df9@github.com>
Message-ID: <wehWKnOivgkBskKS3oLzcAZsZeBzpZjerW6Hf3asWYM=.37f47e9a-9643-4e52-8cc0-59316bcd46a1@github.com>

On Tue, 2 Apr 2024 23:52:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The internal JVM TI `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor the JVM TI function `GetThreadListStackTraces` on the base of `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes.
>> 
>> Testing:
>>  - Ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: cleanup - removed temporary logging used for debugging

Patricio, thank you for prompt review!

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

PR Comment: https://git.openjdk.org/jdk/pull/18574#issuecomment-2033297704

From sspitsyn at openjdk.org  Wed Apr  3 00:00:12 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 3 Apr 2024 00:00:12 GMT
Subject: RFR: 8329491: GetThreadListStackTraces function should use
 JvmtiHandshake [v2]
In-Reply-To: <pn6v4lWYZ_hFamtaLY3dXbpC5mfE6WxK7tmfLvhnZfo=.32a3695c-abc8-4eec-9d6b-47ae0cffc50a@github.com>
References: <56L6f8XFyrB_cUSPTLWNIVhO0PU4w3PjRnpA5U7y_aI=.906bf099-af40-4192-a205-f84120e99ec8@github.com>
 <pn6v4lWYZ_hFamtaLY3dXbpC5mfE6WxK7tmfLvhnZfo=.32a3695c-abc8-4eec-9d6b-47ae0cffc50a@github.com>
Message-ID: <DB8J0GWu8UjFXkaxm0pN7bF1e8-4AwySKz_Vn_jWTpw=.4789dac3-84ca-446e-b3ee-31ef9681812e@github.com>

On Tue, 2 Apr 2024 22:20:12 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: cleanup - removed temporary logging used for debugging
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1986:
> 
>> 1984:   jvmtiError err = JvmtiEnvBase::get_threadOop_and_JavaThread(tlh.list(), target, &java_thread, &thread_obj);
>> 1985:   if (err != JVMTI_ERROR_NONE) {
>> 1986:     printf("DBG: JvmtiHandshake::execute: err: %d\n", (int)err); fflush(0);
> 
> Any reason why not use UL instead with jvmti tag?

Nice catch. The `printf` was temporarily used for debugging. Removed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18574#discussion_r1548752419

From amenkov at openjdk.org  Wed Apr  3 00:26:13 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 3 Apr 2024 00:26:13 GMT
Subject: RFR: JDK-8328137: PreserveAllAnnotations can cause failure of
 class retransformation
In-Reply-To: <oqGiYxyaZPy-jSjMZyOyFJ6Jx8zpA4ryyrMQry-1auo=.49b0b9a1-684f-449a-9498-02c7ba1cb67b@github.com>
References: <eDd0gtG7NpbrXcM3zqdfYxJX91EDDa3qOl6DN60tMVw=.240ea2e6-9533-4980-9074-497fce7f00ce@github.com>
 <oqGiYxyaZPy-jSjMZyOyFJ6Jx8zpA4ryyrMQry-1auo=.49b0b9a1-684f-449a-9498-02c7ba1cb67b@github.com>
Message-ID: <aB_3QD8IPAUSqvYz667yqyxDgTvWLryJM0XwXUjMpDc=.40072b0f-4c3a-482e-957d-6601d72a4eac@github.com>

On Tue, 2 Apr 2024 19:13:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> At one point long ago, I was trying to understand why we have PreserveAllAnnotations and couldn't come up with a reason. For a class file reconstitutor, restoring the invisible annotations to the classfile and then feeding it back to the JVM should have no effect, since the VM doesn't do anything with these annotations.
> 
> I see now why you get the original assert. I think this looks like a reasonable workaround for this problem.
> 
> I wonder if we can deprecate PreserveAllAnnotations. Wonder what it's for? It would need a CSR because it's a product flag.

I also was not able to identify purpose of the flag.
I found couple PRs from 2021 about the flag: #4245 and #4280 with a description of possible usecase for it, but it does not look as a good reason to me.
I'll create a CR to deprecate the flag.

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

PR Comment: https://git.openjdk.org/jdk/pull/18540#issuecomment-2033319487

From amenkov at openjdk.org  Wed Apr  3 00:26:13 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 3 Apr 2024 00:26:13 GMT
Subject: Integrated: JDK-8328137: PreserveAllAnnotations can cause failure of
 class retransformation
In-Reply-To: <eDd0gtG7NpbrXcM3zqdfYxJX91EDDa3qOl6DN60tMVw=.240ea2e6-9533-4980-9074-497fce7f00ce@github.com>
References: <eDd0gtG7NpbrXcM3zqdfYxJX91EDDa3qOl6DN60tMVw=.240ea2e6-9533-4980-9074-497fce7f00ce@github.com>
Message-ID: <x2cGj-SatyAHGHlCtTxBJybHPJQsYur8OdcRcHIYETc=.9f1b7188-b2d8-40ed-bc2b-43dfb7cb5190@github.com>

On Thu, 28 Mar 2024 22:12:49 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> PreserveAllAnnotations option causes class file parser to preserve RuntimeInvisibleAnnotations so VM considers them as RuntimeVisibleAnnotations.
> For class retransformation JvmtiClassFileReconstituter restores all annotations as RuntimeVisibleAnnotations attributes.
> This can cause problem is the class contains only RuntimeInvisibleAnnotations, so corresponding RuntimeVisibleAnnotations attribute name is not present in the class constant pool.
> 
> Correct solution would be to store additional information about RuntimeInvisibleAnnotations and restore them exactly as they were in the original class (this should be done for all annotations: RuntimeInvisibleAnnotations/RuntimeInvisibleTypeAnnotations for class, fields and records, RuntimeInvisibleAnnotations/RuntimeInvisibleTypeAnnotations/RuntimeInvisibleParameterAnnotations for methods; need to ensure the information is correctly updated during class redefinition & retransformation).
> 
> I think it doesn't make sense to add all the complexity for almost no value (I doubt anyone uses PreserveAllAnnotations, the flag looks like experimental, we don't have any tests for it).
> 
> The suggested fix adds workaround for this corner case - if "visible" attribute name is not in the CP, the annotations are restored with "invisible" attribute name.
> 
> Testing:
>   - tier1,tier2,hs-tier5-svc
>   - all java/lang/instrument tests;
>   - all RedefineClasses/RetransformClasses tests

This pull request has now been integrated.

Changeset: f88f31dc
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f88f31dcbf80e9a4cd3ba9d34be8b88128af97c6
Stats:     33 lines in 3 files changed: 22 ins; 0 del; 11 mod

8328137: PreserveAllAnnotations can cause failure of class retransformation

Reviewed-by: coleenp, sspitsyn

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

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

From jpai at openjdk.org  Wed Apr  3 01:00:16 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 3 Apr 2024 01:00:16 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v5]
In-Reply-To: <OKHx2MPKdD8KfHo8DrMsVNIASU461yiCgH2_JB0A3CM=.6038dd44-085b-415f-970a-a33e3d6c29f0@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <OKHx2MPKdD8KfHo8DrMsVNIASU461yiCgH2_JB0A3CM=.6038dd44-085b-415f-970a-a33e3d6c29f0@github.com>
Message-ID: <kgWfaiFMCrvzhuGiWqxLcTEAdH5Tr-n31QeprERgKnA=.df1f42ef-6069-46ff-9985-f0731bb1c5b3@github.com>

On Tue, 2 Apr 2024 16:29:21 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
>> 
>> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
>> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
>> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments.

Thank you for the update, Bill. The latest changes look OK to me.
I also heard from Bill that Alan has approved the changes too.

Before integrating, please run tier1, tier2 and tier3 (I haven't checked which tiers these changed tests belong to) to make sure nothing breaks unexpectedly.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18352#pullrequestreview-1975307573

From sspitsyn at openjdk.org  Wed Apr  3 02:45:13 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 3 Apr 2024 02:45:13 GMT
Subject: RFR: 8313332: Simplify lazy jmethodID cache in InstanceKlass
In-Reply-To: <OnCG3ISfuvt7bIZaKL5fV8PTaZe8KWs56IWc0XdeoYo=.9d61355a-a4fe-4f6c-9a12-805a9f1febc5@github.com>
References: <OnCG3ISfuvt7bIZaKL5fV8PTaZe8KWs56IWc0XdeoYo=.9d61355a-a4fe-4f6c-9a12-805a9f1febc5@github.com>
Message-ID: <uvLPOv4W4UEyy2MjWTOZsSnyZF5qVoclxYk7FpiZNbE=.e94281bd-4941-488e-b7cf-fbd53d82c09a@github.com>

On Fri, 29 Mar 2024 15:25:48 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change simplifies the code that grows the jmethodID cache in InstanceKlass.  Instead of lazily, when there's a rare request for a jmethodID for an obsolete method, the jmethodID cache is grown during the RedefineClasses safepoint.  The InstanceKlass's jmethodID cache is lazily allocated when there's a jmethodID allocated, so not every InstanceKlass has a cache, but the growth now only happens in a safepoint.  This code will become racy with the potential change for deallocating jmethodIDs.
> 
> Tested with tier1-4, vmTestbase/nsk/jvmti java/lang/instrument tests (in case they're not in tier1-4).

src/hotspot/share/oops/instanceKlass.cpp line 2277:

> 2275: jmethodID InstanceKlass::get_jmethod_id(const methodHandle& method_h) {
> 2276:   Method* method = method_h();
> 2277:   int idnum = method_h->method_idnum();

Nit: Can use `method` instead of `method_h()`.

src/hotspot/share/oops/instanceKlass.cpp line 2335:

> 2333:       jmethodID new_id = Method::make_jmethod_id(class_loader_data(), method);
> 2334:       Atomic::release_store(&jmeths[idnum+1], new_id);
> 2335:       return new_id;

Nit: It feels like the function `InstanceKlass::get_jmethod_id()` can be more simplified with a small restructuring:

jmethodID update_jmethod_id(jmethodID* jmeths, Method* method, int idnum) {
  // method_with_idnum
  if (method->is_old() && !method->is_obsolete()) {
    // The method passed in is old (but not obsolete), we need to use the current version
    method = method_with_idnum((int)idnum);
    assert(method != nullptr, "old and but not obsolete, so should exist");
  }
  jmethodID new_id = Method::make_jmethod_id(class_loader_data(), method);
  Atomic::release_store(&jmeths[idnum+1], new_id);
  return new_id;
}

jmethodID InstanceKlass::get_jmethod_id(const methodHandle& method_h) {
  Method* method = method_h();
  int idnum = method_h->method_idnum();
  jmethodID* jmeths = methods_jmethod_ids_acquire();

  <... big comment ...>
  MutexLocker ml(JmethodIdCreation_lock, Mutex::_no_safepoint_check_flag);
  if (jmeths == nullptr) {
    jmeths = methods_jmethod_ids_acquire();

    if (jmeths == nullptr) { // Still null?
      size_t size = idnum_allocated_count();
      assert(size > (size_t)idnum, "should already have space");
      jmeths = NEW_C_HEAP_ARRAY(jmethodID, size+1, mtClass);
      memset(jmeths, 0, (size+1)*sizeof(jmethodID));
      // cache size is stored in element[0], other elements offset by one
      jmeths[0] = (jmethodID)size;
      jmethodID new_id = update_jmethod_id(jmeths, method, idnum);

      // publish jmeths
      release_set_methods_jmethod_ids(jmeths);
      return new_id;
    }
  }
  jmethodID id = Atomic::load_acquire(&jmeths[idnum+1]);
  if (id == nullptr) {
    id = jmeths[idnum+1];

    if (id == nullptr) { // Still null?
      jmethodID new_id = update_jmethod_id(jmeths, method, idnum);
      return new_id;
    }
  }
  return id;
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18549#discussion_r1548840596
PR Review Comment: https://git.openjdk.org/jdk/pull/18549#discussion_r1548839930

From vlivanov at openjdk.org  Wed Apr  3 02:58:00 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 3 Apr 2024 02:58:00 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
 [v2]
In-Reply-To: <eMUTt2ic_OBuS168USvarGBRDCquzLb9AxrSpog1TZw=.d9ae808b-ed03-4971-bd13-db48794a1024@github.com>
References: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
 <eMUTt2ic_OBuS168USvarGBRDCquzLb9AxrSpog1TZw=.d9ae808b-ed03-4971-bd13-db48794a1024@github.com>
Message-ID: <86hdErNCggxb7O-j9AYmcR9IV7M15p1Hnrowo4nDk_U=.1b2b07cd-209b-4181-bc97-58d1a8fac674@github.com>

On Mon, 1 Apr 2024 21:07:31 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Revert [JDK-8152664](https://bugs.openjdk.org/browse/JDK-8152664) RFE [changes](https://github.com/openjdk/jdk/commit/b853eb7f5ca24eeeda18acbb14287f706499c365) which was used for AOT [JEP 295](https://openjdk.org/jeps/295) implementation in JDK 9. The code was left in HotSpot assuming it will help in a future. But during work on Leyden we decided to not use it. In Leyden cached compiled code will be restored in CodeCache as normal nmethods: no need to change VM's runtime and GC code to process them.
>> 
>> I may work on optimizing `CodeBlob` and `nmethod` fields layout to reduce header size in separate changes. In these changes I did simple fields reordering to keep small (1 byte) fields together.
>> 
>> I do not see (and not expected) performance difference with these changes.
>> 
>> Tested tier1-5, xcomp, stress. Running performance testing.
>> 
>> I need help with testing on platforms which Oracle does not support.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed not_used state of nmethod

Nice cleanup! Overall, looks very good.

What about `CompiledMethod_lock`? There's no `CompiledMethod` anymore, but the lock name still refers to it.

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

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18554#pullrequestreview-1975392018

From mbaesken at openjdk.org  Wed Apr  3 08:06:01 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 3 Apr 2024 08:06:01 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v10]
In-Reply-To: <jXp9C900RJWni3Vx_e8h3d1tvim1E3Vs5i53FWO8g1E=.0c0f9f2a-4c6e-42a1-ac19-227a4344f805@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>
 <NM_-NsTTOGAxlIwZlSaVf2TgV3UbcbLxIRA_9gZNY0c=.3aba23e1-a875-46bc-9fa9-6e892e534be8@github.com>
 <LMtCcLS4Vmt2SN3AnXDdKTl1jAlo6Ehp4lZDGGbZxQg=.b10bd71e-fea3-48e7-9c31-4caecee18fe0@github.com>
 <jXp9C900RJWni3Vx_e8h3d1tvim1E3Vs5i53FWO8g1E=.0c0f9f2a-4c6e-42a1-ac19-227a4344f805@github.com>
Message-ID: <yAw0k8FSAAaLP-xgtm4guG3bv3T5pWAGedrQcEGKJPU=.4e64fb46-277e-4ee5-971c-c862ea9d4c54@github.com>

On Fri, 29 Mar 2024 04:15:24 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> There's also a question of whether currently missing doc updates for HeapDumpGzipLevel should be made part of this PR 
> because it complicates back porting.

It should most likely be a separate PR (the title of this one does not match, and there are different backporting needs).

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2033834669

From mbaesken at openjdk.org  Wed Apr  3 09:07:13 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 3 Apr 2024 09:07:13 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v10]
In-Reply-To: <jXp9C900RJWni3Vx_e8h3d1tvim1E3Vs5i53FWO8g1E=.0c0f9f2a-4c6e-42a1-ac19-227a4344f805@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>
 <NM_-NsTTOGAxlIwZlSaVf2TgV3UbcbLxIRA_9gZNY0c=.3aba23e1-a875-46bc-9fa9-6e892e534be8@github.com>
 <LMtCcLS4Vmt2SN3AnXDdKTl1jAlo6Ehp4lZDGGbZxQg=.b10bd71e-fea3-48e7-9c31-4caecee18fe0@github.com>
 <jXp9C900RJWni3Vx_e8h3d1tvim1E3Vs5i53FWO8g1E=.0c0f9f2a-4c6e-42a1-ac19-227a4344f805@github.com>
Message-ID: <x5zxycBv-sMrSoqdYYwYE9fMw7r53sofqTigBzke24A=.3b96b8bc-40b9-4273-8696-e9a5d9b5b65e@github.com>

On Fri, 29 Mar 2024 04:15:24 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> There's still the question of whether or not it is even appropriate to have -XX options taking the place of jcmd options.

Some people (like our cloud support colleagues and also some who commented) would like this approach, some find it not very useful.
Seems there are also already other globals flags playing a role in diagnosticCommand coding (e.g. RecordDynamicDumpInfo, maybe more) so it is not completely 'new' that the jcmd commands are influenced by globals flag.
Looking at just the _names_ of  HeapDumpPath and also  HeapDumpGzipLevel   I would think that they play a role for all heap dumps and not just some.

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2033985633

From ihse at openjdk.org  Wed Apr  3 10:04:01 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 3 Apr 2024 10:04:01 GMT
Subject: RFR: JDK-8303689: javac -Xlint could/should report on "dangling"
 doc comments
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <CJk_cgw_oK69SgmEsA7fC7wupoZ6Uc_MJ_vAEFUhMlc=.3b61473c-97e6-4a9a-b19b-e387ab9eb5ab@github.com>

On Wed, 27 Mar 2024 22:04:30 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

The build changes look okay. 

Do you have any plan of going through all the Java modules and fixing the issues, or opening JBS issues to have them fixed? Or will these lint warnings remain disabled for the foreseeable future?

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18527#pullrequestreview-1976255818

From kevinw at openjdk.org  Wed Apr  3 10:12:09 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 3 Apr 2024 10:12:09 GMT
Subject: RFR: JDK-8322042: HeapDumper should perform merge on the current
 thread instead of VMThread [v2]
In-Reply-To: <5DSzGDsLSswF0y1iWTfoq0kYpZqXPqVLgN4lItTF1EE=.2989a521-e453-41fb-89e8-3aabe478f8a8@github.com>
References: <4--MamzddI0M3jpWu5NG1OvvX2aOo1vTUsH0TNYmty0=.9c4f04fc-2809-427f-9109-6a2f8be3ca5a@github.com>
 <5DSzGDsLSswF0y1iWTfoq0kYpZqXPqVLgN4lItTF1EE=.2989a521-e453-41fb-89e8-3aabe478f8a8@github.com>
Message-ID: <VRgP2qovkj_wGSndk6nnQGyIGuepx4FvkQwDpCioEPg=.185b5baa-474e-406f-a297-379552159438@github.com>

On Tue, 2 Apr 2024 21:13:33 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updated HeapDumper to always perform merge on the current thread.
>> 
>> Testing: tier1-5, all HeapDump-related tests
>>   Covered heap dumping scenarios:
>>     - `jcmd GC.heap_dump` command;
>>     - `HotSpotDiagnosticMXBean.dumpHeap()`;
>>     - `HeapDumpBeforeFullGC`, `HeapDumpAfterFullGC` VM options;
>>     - `HeapDumpOnOutOfMemoryError` VM option.
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment

Are we saying there is never any need to perform the merge in a VM Operation?
Originally (JDK-8306441) it's either done in the attach thread, or a VM operation if we are in another thread. But maybe that was just being cautious.

Keeping only the invoking thread busy, rather than a VM Operation, sounds like a good goal.

I'm interested in if we can hit a problem by causing multiple heap dumps at once, e.g. jcmd, the app calling the MXBean, and maybe even the OnOOM trigger as well, could all happen at the same time. 8-)

Using the MXBean, we may be able to make multiple heap dumps concurrently (either multiple MXBean invocations, or one MXBean invocation while a jcmd runs...).

jcmd keeps the atttach listener thread busy, so we can't have concurrent dumps from that method.  I think that explains the original code, where all other methods use the VM Operation.

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

PR Review: https://git.openjdk.org/jdk/pull/18571#pullrequestreview-1976273140

From coleenp at openjdk.org  Wed Apr  3 12:25:15 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 3 Apr 2024 12:25:15 GMT
Subject: RFR: 8236736: Change notproduct JVM flags to develop flags [v4]
In-Reply-To: <vD-L2x7FsbI73-fnKI9gis14awM8xL-IPeXzDfMYUqE=.c5c01067-f446-4538-8b66-b522a3cdbd2f@github.com>
References: <25c1XDQrzxvG0AuxlRjQyznnTdLzD1-J4kebuXzj-Zc=.0f5d28e1-7672-40a9-97fe-04a77fda65d9@github.com>
 <vD-L2x7FsbI73-fnKI9gis14awM8xL-IPeXzDfMYUqE=.c5c01067-f446-4538-8b66-b522a3cdbd2f@github.com>
Message-ID: <RKR7PwZ9Jy5DEdM9_X1YvCwZFUSQlB7c9pIVqVQXMek=.9b9ec1e6-d84e-4758-9427-0966ac0ab7de@github.com>

On Tue, 2 Apr 2024 19:47:23 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Remove the notproduct distinction for command line options, rather than trying to wrestle the macros to fix the bug that they've been treated as develop options for some time now.  This simplifies the command line option macros.
>> 
>> Tested with tier1-4, tier1 on Oracle platforms.  Also built shenandoah.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant test case.

Thanks for the reviews, Ioi, Vladimir, Kim and Stefan.

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

PR Comment: https://git.openjdk.org/jdk/pull/18541#issuecomment-2034433313

From coleenp at openjdk.org  Wed Apr  3 12:25:15 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 3 Apr 2024 12:25:15 GMT
Subject: Integrated: 8236736: Change notproduct JVM flags to develop flags
In-Reply-To: <25c1XDQrzxvG0AuxlRjQyznnTdLzD1-J4kebuXzj-Zc=.0f5d28e1-7672-40a9-97fe-04a77fda65d9@github.com>
References: <25c1XDQrzxvG0AuxlRjQyznnTdLzD1-J4kebuXzj-Zc=.0f5d28e1-7672-40a9-97fe-04a77fda65d9@github.com>
Message-ID: <Wce-Ho-45jQ48BQrSNonpRwYaVfZkD4Lc9xFGQXCA28=.6fca587d-5154-495d-91fb-240d28efb5d5@github.com>

On Thu, 28 Mar 2024 22:53:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Remove the notproduct distinction for command line options, rather than trying to wrestle the macros to fix the bug that they've been treated as develop options for some time now.  This simplifies the command line option macros.
> 
> Tested with tier1-4, tier1 on Oracle platforms.  Also built shenandoah.

This pull request has now been integrated.

Changeset: bea493bc
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bea493bcb86370dc3fb00d86c545f01fc614e000
Stats:     282 lines in 43 files changed: 1 ins; 102 del; 179 mod

8236736: Change notproduct JVM flags to develop flags

Reviewed-by: iklam, kvn, kbarrett

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

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

From coleenp at openjdk.org  Wed Apr  3 12:45:09 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 3 Apr 2024 12:45:09 GMT
Subject: RFR: 8313332: Simplify lazy jmethodID cache in InstanceKlass
In-Reply-To: <uvLPOv4W4UEyy2MjWTOZsSnyZF5qVoclxYk7FpiZNbE=.e94281bd-4941-488e-b7cf-fbd53d82c09a@github.com>
References: <OnCG3ISfuvt7bIZaKL5fV8PTaZe8KWs56IWc0XdeoYo=.9d61355a-a4fe-4f6c-9a12-805a9f1febc5@github.com>
 <uvLPOv4W4UEyy2MjWTOZsSnyZF5qVoclxYk7FpiZNbE=.e94281bd-4941-488e-b7cf-fbd53d82c09a@github.com>
Message-ID: <Z9DcORj81lNt4hrxhDsQpM9jlIU-fkkUEn769nOfVYQ=.14826495-4cec-492c-9b96-a36e8c58a63f@github.com>

On Wed, 3 Apr 2024 02:41:06 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This change simplifies the code that grows the jmethodID cache in InstanceKlass.  Instead of lazily, when there's a rare request for a jmethodID for an obsolete method, the jmethodID cache is grown during the RedefineClasses safepoint.  The InstanceKlass's jmethodID cache is lazily allocated when there's a jmethodID allocated, so not every InstanceKlass has a cache, but the growth now only happens in a safepoint.  This code will become racy with the potential change for deallocating jmethodIDs.
>> 
>> Tested with tier1-4, vmTestbase/nsk/jvmti java/lang/instrument tests (in case they're not in tier1-4).
>
> src/hotspot/share/oops/instanceKlass.cpp line 2335:
> 
>> 2333:       jmethodID new_id = Method::make_jmethod_id(class_loader_data(), method);
>> 2334:       Atomic::release_store(&jmeths[idnum+1], new_id);
>> 2335:       return new_id;
> 
> Nit: It feels like the function `InstanceKlass::get_jmethod_id()` can be more simplified with a small restructuring:
> 
> jmethodID update_jmethod_id(jmethodID* jmeths, Method* method, int idnum) {
>   // method_with_idnum
>   if (method->is_old() && !method->is_obsolete()) {
>     // The method passed in is old (but not obsolete), we need to use the current version
>     method = method_with_idnum((int)idnum);
>     assert(method != nullptr, "old and but not obsolete, so should exist");
>   }
>   jmethodID new_id = Method::make_jmethod_id(class_loader_data(), method);
>   Atomic::release_store(&jmeths[idnum+1], new_id);
>   return new_id;
> }
> 
> jmethodID InstanceKlass::get_jmethod_id(const methodHandle& method_h) {
>   Method* method = method_h();
>   int idnum = method_h->method_idnum();
>   jmethodID* jmeths = methods_jmethod_ids_acquire();
> 
>   <... big comment ...>
>   MutexLocker ml(JmethodIdCreation_lock, Mutex::_no_safepoint_check_flag);
>   if (jmeths == nullptr) {
>     jmeths = methods_jmethod_ids_acquire();
> 
>     if (jmeths == nullptr) { // Still null?
>       size_t size = idnum_allocated_count();
>       assert(size > (size_t)idnum, "should already have space");
>       jmeths = NEW_C_HEAP_ARRAY(jmethodID, size+1, mtClass);
>       memset(jmeths, 0, (size+1)*sizeof(jmethodID));
>       // cache size is stored in element[0], other elements offset by one
>       jmeths[0] = (jmethodID)size;
>       jmethodID new_id = update_jmethod_id(jmeths, method, idnum);
> 
>       // publish jmeths
>       release_set_methods_jmethod_ids(jmeths);
>       return new_id;
>     }
>   }
>   jmethodID id = Atomic::load_acquire(&jmeths[idnum+1]);
>   if (id == nullptr) {
>     id = jmeths[idnum+1];
> 
>     if (id == nullptr) { // Still null?
>       jmethodID new_id = update_jmethod_id(jmeths, method, idnum);
>       return new_id;
>     }
>   }
>   return id;
> }

Yes this refactoring looks nice.  Nice to have only one place that checks for !is_obsolete.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18549#discussion_r1549664452

From coleenp at openjdk.org  Wed Apr  3 13:25:36 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 3 Apr 2024 13:25:36 GMT
Subject: RFR: 8313332: Simplify lazy jmethodID cache in InstanceKlass [v2]
In-Reply-To: <OnCG3ISfuvt7bIZaKL5fV8PTaZe8KWs56IWc0XdeoYo=.9d61355a-a4fe-4f6c-9a12-805a9f1febc5@github.com>
References: <OnCG3ISfuvt7bIZaKL5fV8PTaZe8KWs56IWc0XdeoYo=.9d61355a-a4fe-4f6c-9a12-805a9f1febc5@github.com>
Message-ID: <wvi9xtVpx60MtuF-E-sRNlo_oFPHkxQwkieshGJ4m8Q=.462eb904-91a1-4188-ba6f-ed49bbf7b0ec@github.com>

> This change simplifies the code that grows the jmethodID cache in InstanceKlass.  Instead of lazily, when there's a rare request for a jmethodID for an obsolete method, the jmethodID cache is grown during the RedefineClasses safepoint.  The InstanceKlass's jmethodID cache is lazily allocated when there's a jmethodID allocated, so not every InstanceKlass has a cache, but the growth now only happens in a safepoint.  This code will become racy with the potential change for deallocating jmethodIDs.
> 
> Tested with tier1-4, vmTestbase/nsk/jvmti java/lang/instrument tests (in case they're not in tier1-4).

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Refactoring suggested by Serguei.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18549/files
  - new: https://git.openjdk.org/jdk/pull/18549/files/ffffe38f..6576d14d

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

  Stats: 32 lines in 2 files changed: 12 ins; 16 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/18549.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18549/head:pull/18549

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

From coleenp at openjdk.org  Wed Apr  3 13:25:36 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 3 Apr 2024 13:25:36 GMT
Subject: RFR: 8313332: Simplify lazy jmethodID cache in InstanceKlass [v2]
In-Reply-To: <Z9DcORj81lNt4hrxhDsQpM9jlIU-fkkUEn769nOfVYQ=.14826495-4cec-492c-9b96-a36e8c58a63f@github.com>
References: <OnCG3ISfuvt7bIZaKL5fV8PTaZe8KWs56IWc0XdeoYo=.9d61355a-a4fe-4f6c-9a12-805a9f1febc5@github.com>
 <uvLPOv4W4UEyy2MjWTOZsSnyZF5qVoclxYk7FpiZNbE=.e94281bd-4941-488e-b7cf-fbd53d82c09a@github.com>
 <Z9DcORj81lNt4hrxhDsQpM9jlIU-fkkUEn769nOfVYQ=.14826495-4cec-492c-9b96-a36e8c58a63f@github.com>
Message-ID: <urcIxqQ0GafxGg_BxaSTls2Ec0qLdudx1a-ChBcWHdY=.f90dde37-950f-4af5-9b06-3b9a342b989c@github.com>

On Wed, 3 Apr 2024 12:42:30 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/oops/instanceKlass.cpp line 2335:
>> 
>>> 2333:       jmethodID new_id = Method::make_jmethod_id(class_loader_data(), method);
>>> 2334:       Atomic::release_store(&jmeths[idnum+1], new_id);
>>> 2335:       return new_id;
>> 
>> Nit: It feels like the function `InstanceKlass::get_jmethod_id()` can be more simplified with a small restructuring:
>> 
>> jmethodID update_jmethod_id(jmethodID* jmeths, Method* method, int idnum) {
>>   // method_with_idnum
>>   if (method->is_old() && !method->is_obsolete()) {
>>     // The method passed in is old (but not obsolete), we need to use the current version
>>     method = method_with_idnum((int)idnum);
>>     assert(method != nullptr, "old and but not obsolete, so should exist");
>>   }
>>   jmethodID new_id = Method::make_jmethod_id(class_loader_data(), method);
>>   Atomic::release_store(&jmeths[idnum+1], new_id);
>>   return new_id;
>> }
>> 
>> jmethodID InstanceKlass::get_jmethod_id(const methodHandle& method_h) {
>>   Method* method = method_h();
>>   int idnum = method_h->method_idnum();
>>   jmethodID* jmeths = methods_jmethod_ids_acquire();
>> 
>>   <... big comment ...>
>>   MutexLocker ml(JmethodIdCreation_lock, Mutex::_no_safepoint_check_flag);
>>   if (jmeths == nullptr) {
>>     jmeths = methods_jmethod_ids_acquire();
>> 
>>     if (jmeths == nullptr) { // Still null?
>>       size_t size = idnum_allocated_count();
>>       assert(size > (size_t)idnum, "should already have space");
>>       jmeths = NEW_C_HEAP_ARRAY(jmethodID, size+1, mtClass);
>>       memset(jmeths, 0, (size+1)*sizeof(jmethodID));
>>       // cache size is stored in element[0], other elements offset by one
>>       jmeths[0] = (jmethodID)size;
>>       jmethodID new_id = update_jmethod_id(jmeths, method, idnum);
>> 
>>       // publish jmeths
>>       release_set_methods_jmethod_ids(jmeths);
>>       return new_id;
>>     }
>>   }
>>   jmethodID id = Atomic::load_acquire(&jmeths[idnum+1]);
>>   if (id == nullptr) {
>>     id = jmeths[idnum+1];
>> 
>>     if (id == nullptr) { // Still null?
>>       jmethodID new_id = update_jmethod_id(jmeths, method, idnum);
>>       return new_id;
>>     }
>>   }
>>   return id;
>> }
>
> Yes this refactoring looks nice.  Nice to have only one place that checks for !is_obsolete.

Thank you for the suggestion, I reran the jvmti tests locally.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18549#discussion_r1549733870

From clanger at openjdk.org  Wed Apr  3 13:41:14 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 3 Apr 2024 13:41:14 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v10]
In-Reply-To: <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>
Message-ID: <S5HlZ9fPPANZHjyo_ZLBOv8OKqBNO06D8obHDri9tOw=.005a650a-11b0-4347-a92e-c0c48984155a@github.com>

On Wed, 27 Mar 2024 13:44:42 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently jcmd command GC.heap_dump only works with an additionally provided file name.
>> Syntax : GC.heap_dump [options] <filename>
>> 
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the <filename> is optional.
>> In case the filename is NOT set, we take the HeapDumpPath (file or directory);
>> 
>> new syntax :
>> GC.heap_dump [options] <filename> .. has precedence over second option
>> GC.heap_dump [options] ?in case -XX: HeapDumpPath=p is set
>> 
>> This would be a simplification e.g. for support cases where a filename or directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the path is intended/recommended for usage also in the jcmd case.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust java.1 man page

Couldn't we just have an unconditional default for the GC.heap_dump `filename` option? This would simplify the documentation. E.g. we could write `If not specified, defaults to java_pid<pid>.hprof in the working directory or value configured through -XX:HeapDumpPath`

As for the general value of this feature, I think it can simplify the handling of certain (cloud) deployment configurations where you have a dedicated filesystem that you want to write these kind of dumps to. It might also be nice if there was a default value for filename instead of the obligation to specify something. And, for those who can't see the upside of it all, I at least can't see no harm...

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2034639628

From stefank at openjdk.org  Wed Apr  3 16:03:14 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 3 Apr 2024 16:03:14 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
 [v2]
In-Reply-To: <eMUTt2ic_OBuS168USvarGBRDCquzLb9AxrSpog1TZw=.d9ae808b-ed03-4971-bd13-db48794a1024@github.com>
References: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
 <eMUTt2ic_OBuS168USvarGBRDCquzLb9AxrSpog1TZw=.d9ae808b-ed03-4971-bd13-db48794a1024@github.com>
Message-ID: <2MTKEcGChvwWqFFuPs-5TR8GJnLwrnrgGKqdIV4NX70=.d0a707d4-5dfc-467c-992d-d410f94a7dca@github.com>

On Mon, 1 Apr 2024 21:07:31 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Revert [JDK-8152664](https://bugs.openjdk.org/browse/JDK-8152664) RFE [changes](https://github.com/openjdk/jdk/commit/b853eb7f5ca24eeeda18acbb14287f706499c365) which was used for AOT [JEP 295](https://openjdk.org/jeps/295) implementation in JDK 9. The code was left in HotSpot assuming it will help in a future. But during work on Leyden we decided to not use it. In Leyden cached compiled code will be restored in CodeCache as normal nmethods: no need to change VM's runtime and GC code to process them.
>> 
>> I may work on optimizing `CodeBlob` and `nmethod` fields layout to reduce header size in separate changes. In these changes I did simple fields reordering to keep small (1 byte) fields together.
>> 
>> I do not see (and not expected) performance difference with these changes.
>> 
>> Tested tier1-5, xcomp, stress. Running performance testing.
>> 
>> I need help with testing on platforms which Oracle does not support.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed not_used state of nmethod

Nice!

We've wanted to clean up some interfaces between the CodeCache and the GC code by using nmethod closures instead of CodeBlob closures. This change (and the Sweeper removal) makes it possible to do those cleanups.

I've made a superficial pass over the patch to and left a few comments. Most of those comments are things that would be nice to fix, but could also be left as follow-up RFEs (if they are deemed to be worthy ideas to pursue).

src/hotspot/os/posix/signals_posix.cpp line 27:

> 25: #include "precompiled.hpp"
> 26: #include "code/codeCache.hpp"
> 27: #include "code/nmethod.hpp"

The include line needs to move down.

src/hotspot/share/code/codeBlob.hpp line 77:

> 75: //   - data space
> 76: 
> 77: enum CodeBlobKind : u1 {

It will probably be safer to change this to an enum class, so that the compiler will help us if we mess up with the argument order when this is used in function calls. I see that this patch switches the parameter order of some functions, so I think it could be worth trying out.

src/hotspot/share/code/codeBlob.hpp line 409:

> 407: 
> 408:   // GC/Verification support
> 409:   virtual void preserve_callee_argument_oops(frame fr, const RegisterMap *reg_map, OopClosure* f) override { /* nothing to do */ }

In the GC code we usually have either virtual OR override, but not both. Could we skip `virtual` here? Or does the compiler code usually use both?

src/hotspot/share/code/codeBlob.hpp line 429:

> 427:    SingletonBlob(
> 428:      const char* name,
> 429:      CodeBlobKind kind,

There's an alignment issue after this change.

src/hotspot/share/code/codeCache.cpp line 1009:

> 1007: int CodeCache::nmethod_count() {
> 1008:   int count = 0;
> 1009:   for (GrowableArrayIterator<CodeHeap*> heap = _nmethod_heaps->begin(); heap != _nmethod_heaps->end(); ++heap) {

Is there a reason why FOR_ALL_NMETHOD_HEAPS wasn't good fit here? I'm wondering since the similar `CodeCache::blob_count()` still uses one of these macros.

src/hotspot/share/code/nmethod.cpp line 812:

> 810:     // By calling this nmethod entry barrier, it plays along and acts
> 811:     // like any other nmethod found on the stack of a thread (fewer surprises).
> 812:     nmethod* nm = as_nmethod_or_null();

Calling as_nmethod_or_null() from within functions in the nmethod class is suspicious. Shouldn't all such usages be removed? (I'm fine with doing that as a separate change)

src/hotspot/share/code/nmethod.cpp line 1009:

> 1007: // Fill in default values for various flag fields
> 1008: void nmethod::init_defaults() {
> 1009:   { // avoid uninitialized fields, even for short time periods

Should these curly braces be removed?

src/hotspot/share/code/nmethod.cpp line 2164:

> 2162:   DTRACE_METHOD_UNLOAD_PROBE(method());
> 2163: 
> 2164:   // If a JVMTI agent has enabled the nmethod Unload event then

I think the event is still called CompiledMethodUnload, so this line should probably be reverted.

src/hotspot/share/code/nmethod.hpp line 50:

> 48: class ScopeDesc;
> 49: class CompiledIC;
> 50: class MetadataClosure;

Maybe merge (and sort) this together with the other forward declarations?

src/hotspot/share/code/nmethod.hpp line 905:

> 903: 
> 904:   // printing support
> 905:   void print()                          const override;

Here and a few other places you only use override and not also virtual. This is inconsistent with other functions in this class. (FWIW, I prefer this style with only the override qualifier).

src/hotspot/share/code/nmethod.inline.hpp line 60:

> 58: // (b) it is a deopt PC
> 59: 
> 60: inline address nmethod::get_deopt_original_pc(const frame* fr) {

While reading this PR I wonder if this really belongs in the `nmethod` class or if it would make more sense to have it as a member function in the `frame` class. It is a static function, which uses `fr` sort-of like a `this` pointer. Maybe something to consider for a separate RFE.

src/hotspot/share/code/relocInfo.hpp line 39:

> 37: class nmethod;
> 38: class CodeBlob;
> 39: class nmethod;

You already have a class nmethod forward declaration above.

src/hotspot/share/compiler/compileBroker.cpp line 1379:

> 1377:   if (osr_bci == InvocationEntryBci) {
> 1378:     // standard compilation
> 1379:     nmethod* method_code = method->code();

Isn't the `method_code->is_nmethod()` redundant now?

src/hotspot/share/compiler/compileBroker.cpp line 1484:

> 1482:   // We accept a higher level osr method
> 1483:   if (osr_bci == InvocationEntryBci) {
> 1484:     nmethod* code = method->code();

Cast below is redundant.

src/hotspot/share/gc/g1/g1HeapRegion.cpp line 339:

> 337: 
> 338:   void do_code_blob(CodeBlob* cb) {
> 339:     nmethod* nm = (cb == nullptr) ? nullptr : cb->as_nmethod_or_null();

After this change I'd like to see if we can change this and similar GC interfaces to work directly against `nmethod` instead of `CodeBlob`.

src/hotspot/share/gc/shared/parallelCleaning.cpp line 54:

> 52: void CodeCacheUnloadingTask::claim_nmethods(nmethod** claimed_nmethods, int *num_claimed_nmethods) {
> 53:   nmethod* first;
> 54:   NMethodIterator last(NMethodIterator::all_blobs);

FWIW, `all_blobs` is slightly confusing name when nmethods are a subset of all "code blobs". We might want to consider renaming this to `NMethodIterator::all` (in a separate RFE).

src/hotspot/share/gc/x/xUnload.cpp line 78:

> 76: class XIsUnloadingBehaviour : public IsUnloadingBehaviour {
> 77: public:
> 78:   virtual bool has_dead_oop(nmethod* method) const {

This now takes an `nmethod` argument, but still calls as_nmethod(). I think that should be removed from this, and all similar functions here in the GC code. If you want, I can do that as a follow-up RFE.

src/hotspot/share/jvmci/jvmciRuntime.cpp line 271:

> 269: 
> 270:   nm = CodeCache::find_nmethod(pc);
> 271:   assert(nm != nullptr, "this is not a compiled method");

Unrelated to this patch, but might be worth mentioning because I think it would be good to think about this in a follow-up RFE. `CodeCache::find_blob` returns null if it can't find a matching blob, but `CodeCache::find_nmethod` asserts that it did find one. The latter makes the assert redundant, but it also begs to question if `find_blob` and `find_nmethod` realy should be different in this regard? Should we have `find_blob_or_null` and `find_nmethod_or_null`? Alt. `find_blob_not_null` and `find_nmethod_not_null`.

src/hotspot/share/prims/whitebox.cpp line 772:

> 770:             if (_make_not_entrant) {
> 771:                 nmethod* nm = CodeCache::find_nmethod(f->pc());
> 772:                 assert(nm != nullptr, "sanity check");

This assert is now redundant.

src/hotspot/share/prims/whitebox.cpp line 1100:

> 1098:   // Check code again because compilation may be finished before Compile_lock is acquired.
> 1099:   if (bci == InvocationEntryBci) {
> 1100:     nmethod* code = mh->code();

`as_nmethod_or_null()` below should be redundant.

src/hotspot/share/runtime/continuationEntry.hpp line 35:

> 33: #include CPU_HEADER(continuationEntry)
> 34: 
> 35: class nmethod;

Maybe keep the forward declarations sorted?

src/hotspot/share/runtime/continuationEntry.hpp line 59:

> 57: public:
> 58:   static int _return_pc_offset; // friend gen_continuation_enter
> 59:   static void set_enter_code(nmethod* cm, int interpreted_entry_offset);

cm => nm?

src/hotspot/share/runtime/frame.cpp line 208:

> 206: address frame::raw_pc() const {
> 207:   if (is_deoptimized_frame()) {
> 208:     nmethod* nm = cb()->as_nmethod_or_null();

Prexisting: It's weird that this code is using the `_or_null()` version when the code below does not null check the returned value.

src/hotspot/share/runtime/vframe.cpp line 75:

> 73:   if (cb != nullptr) {
> 74:     if (cb->is_nmethod()) {
> 75:       nmethod* nm = cb->as_nmethod();;

There's two `;`s on this line.

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

PR Review: https://git.openjdk.org/jdk/pull/18554#pullrequestreview-1977027234
PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1549873079
PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1549892107
PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1549895707
PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1549917406
PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1549925499
PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1549949611
PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1549954407
PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1549955841
PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1549958927
PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1549968764
PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1549974539
PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1549975722
PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1549977276
PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1549978007
PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1549979750
PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1549983251
PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1549985971
PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1549992086
PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1549999765
PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1550002167
PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1550005072
PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1550006055
PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1550013866
PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1550025081

From kvn at openjdk.org  Wed Apr  3 16:18:12 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 3 Apr 2024 16:18:12 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
 [v2]
In-Reply-To: <86hdErNCggxb7O-j9AYmcR9IV7M15p1Hnrowo4nDk_U=.1b2b07cd-209b-4181-bc97-58d1a8fac674@github.com>
References: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
 <eMUTt2ic_OBuS168USvarGBRDCquzLb9AxrSpog1TZw=.d9ae808b-ed03-4971-bd13-db48794a1024@github.com>
 <86hdErNCggxb7O-j9AYmcR9IV7M15p1Hnrowo4nDk_U=.1b2b07cd-209b-4181-bc97-58d1a8fac674@github.com>
Message-ID: <8Eb7EtxdXdDbbgICKduteW4cHuINHpbQevdPJ7XBvYY=.594146f6-87f3-41ed-86a7-3e6541d67286@github.com>

On Wed, 3 Apr 2024 02:55:52 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> What about `CompiledMethod_lock`? There's no `CompiledMethod` anymore, but the lock name still refers to it.

It was different changes [JDK-8226705](https://bugs.openjdk.org/browse/JDK-8226705). Renaming it will complicate these changes more than I wanted. I can do it in separate RFE.

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

PR Comment: https://git.openjdk.org/jdk/pull/18554#issuecomment-2035031413

From sspitsyn at openjdk.org  Wed Apr  3 16:27:12 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 3 Apr 2024 16:27:12 GMT
Subject: RFR: 8313332: Simplify lazy jmethodID cache in InstanceKlass [v2]
In-Reply-To: <wvi9xtVpx60MtuF-E-sRNlo_oFPHkxQwkieshGJ4m8Q=.462eb904-91a1-4188-ba6f-ed49bbf7b0ec@github.com>
References: <OnCG3ISfuvt7bIZaKL5fV8PTaZe8KWs56IWc0XdeoYo=.9d61355a-a4fe-4f6c-9a12-805a9f1febc5@github.com>
 <wvi9xtVpx60MtuF-E-sRNlo_oFPHkxQwkieshGJ4m8Q=.462eb904-91a1-4188-ba6f-ed49bbf7b0ec@github.com>
Message-ID: <VeaWT_rsZ6bHIw40BI9efldborzgxnLBy3-9FSuHli4=.2801009d-4d63-43a6-8b5a-a3f7f187c717@github.com>

On Wed, 3 Apr 2024 13:25:36 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change simplifies the code that grows the jmethodID cache in InstanceKlass.  Instead of lazily, when there's a rare request for a jmethodID for an obsolete method, the jmethodID cache is grown during the RedefineClasses safepoint.  The InstanceKlass's jmethodID cache is lazily allocated when there's a jmethodID allocated, so not every InstanceKlass has a cache, but the growth now only happens in a safepoint.  This code will become racy with the potential change for deallocating jmethodIDs.
>> 
>> Tested with tier1-4, vmTestbase/nsk/jvmti java/lang/instrument tests (in case they're not in tier1-4).
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactoring suggested by Serguei.

Looks good to me. Nice simplification.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18549#pullrequestreview-1977358735

From kvn at openjdk.org  Wed Apr  3 16:32:12 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 3 Apr 2024 16:32:12 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
 [v2]
In-Reply-To: <2MTKEcGChvwWqFFuPs-5TR8GJnLwrnrgGKqdIV4NX70=.d0a707d4-5dfc-467c-992d-d410f94a7dca@github.com>
References: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
 <eMUTt2ic_OBuS168USvarGBRDCquzLb9AxrSpog1TZw=.d9ae808b-ed03-4971-bd13-db48794a1024@github.com>
 <2MTKEcGChvwWqFFuPs-5TR8GJnLwrnrgGKqdIV4NX70=.d0a707d4-5dfc-467c-992d-d410f94a7dca@github.com>
Message-ID: <XLp_PiTfgwtq8j7xWRuhEPSChBsUcBYgkzrJbHpG1nU=.b29ceb12-830e-43e8-ab9e-d587c6dffd03@github.com>

On Wed, 3 Apr 2024 14:44:03 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed not_used state of nmethod
>
> src/hotspot/share/code/codeBlob.hpp line 409:
> 
>> 407: 
>> 408:   // GC/Verification support
>> 409:   virtual void preserve_callee_argument_oops(frame fr, const RegisterMap *reg_map, OopClosure* f) override { /* nothing to do */ }
> 
> In the GC code we usually have either virtual OR override, but not both. Could we skip `virtual` here? Or does the compiler code usually use both?

No special rules here. I simply want to see all `virtual` methods explicitly and `override` is required by C++.
I would like to keep it this way in these changes. I am investigating possibility to convert all these virtual methods to normal one to remove virtual table and virtual pointer (8 bytes) from CodeBlob class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1550071713

From kvn at openjdk.org  Wed Apr  3 16:40:59 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 3 Apr 2024 16:40:59 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
 [v2]
In-Reply-To: <2MTKEcGChvwWqFFuPs-5TR8GJnLwrnrgGKqdIV4NX70=.d0a707d4-5dfc-467c-992d-d410f94a7dca@github.com>
References: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
 <eMUTt2ic_OBuS168USvarGBRDCquzLb9AxrSpog1TZw=.d9ae808b-ed03-4971-bd13-db48794a1024@github.com>
 <2MTKEcGChvwWqFFuPs-5TR8GJnLwrnrgGKqdIV4NX70=.d0a707d4-5dfc-467c-992d-d410f94a7dca@github.com>
Message-ID: <krSXrZzWLlgmaN_nvIgBhdbR75PQqpRcU3H4EBCdtP4=.b378adba-bff1-424f-b07d-d80c641e6608@github.com>

On Wed, 3 Apr 2024 15:01:22 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed not_used state of nmethod
>
> src/hotspot/share/code/codeCache.cpp line 1009:
> 
>> 1007: int CodeCache::nmethod_count() {
>> 1008:   int count = 0;
>> 1009:   for (GrowableArrayIterator<CodeHeap*> heap = _nmethod_heaps->begin(); heap != _nmethod_heaps->end(); ++heap) {
> 
> Is there a reason why FOR_ALL_NMETHOD_HEAPS wasn't good fit here? I'm wondering since the similar `CodeCache::blob_count()` still uses one of these macros.

No,  `CodeCache::blob_count()` uses different macro `FOR_ALL_HEAPS(heap)` because it looks for all code blobs, not only nmethods.

`CodeCache::nmethod_count()` is the only place where `FOR_ALL_NMETHOD_HEAPS ` was used. So I decided to remove the macro.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1550087255

From kvn at openjdk.org  Wed Apr  3 17:01:10 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 3 Apr 2024 17:01:10 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
 [v2]
In-Reply-To: <2MTKEcGChvwWqFFuPs-5TR8GJnLwrnrgGKqdIV4NX70=.d0a707d4-5dfc-467c-992d-d410f94a7dca@github.com>
References: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
 <eMUTt2ic_OBuS168USvarGBRDCquzLb9AxrSpog1TZw=.d9ae808b-ed03-4971-bd13-db48794a1024@github.com>
 <2MTKEcGChvwWqFFuPs-5TR8GJnLwrnrgGKqdIV4NX70=.d0a707d4-5dfc-467c-992d-d410f94a7dca@github.com>
Message-ID: <mlT7PVOHFFZO7Jwl2QfwOiezYsYFdu7u0w_nzokVe4A=.3cb7886c-3d09-44aa-a06f-d4288b833fda@github.com>

On Wed, 3 Apr 2024 15:12:31 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed not_used state of nmethod
>
> src/hotspot/share/code/nmethod.cpp line 812:
> 
>> 810:     // By calling this nmethod entry barrier, it plays along and acts
>> 811:     // like any other nmethod found on the stack of a thread (fewer surprises).
>> 812:     nmethod* nm = as_nmethod_or_null();
> 
> Calling as_nmethod_or_null() from within functions in the nmethod class is suspicious. Shouldn't all such usages be removed? (I'm fine with doing that as a separate change)

Good catch! The code was moved from CompiledMethod where it made sense but now it is not needed. Here the change I will make:

     // like any other nmethod found on the stack of a thread (fewer surprises).
-    nmethod* nm = as_nmethod_or_null();
-    if (nm != nullptr && bs_nm->is_armed(nm)) {
+    nmethod* nm = this;
+    if (bs_nm->is_armed(nm)) {
       bool alive = bs_nm->nmethod_entry_barrier(nm);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1550118967

From bhuang at openjdk.org  Wed Apr  3 17:07:12 2024
From: bhuang at openjdk.org (Bill Huang)
Date: Wed, 3 Apr 2024 17:07:12 GMT
Subject: Integrated: JDK-8327474 Review use of java.io.tmpdir in jdk tests
In-Reply-To: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
Message-ID: <4fPL8biQ1uu8AMKMNmt3x0yLRKa01iDp6OL5MXQgasM=.bc20a303-65dc-48b2-80eb-b9ef6cd15b00@github.com>

On Mon, 18 Mar 2024 16:47:24 GMT, Bill Huang <bhuang at openjdk.org> wrote:

> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
> 
> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.

This pull request has now been integrated.

Changeset: 375bfac8
Author:    Bill Huang <bhuang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/375bfac8e7ff3f871e2d986876f91a5fba200c83
Stats:     193 lines in 11 files changed: 66 ins; 13 del; 114 mod

8327474: Review use of java.io.tmpdir in jdk tests

Reviewed-by: michaelm, jpai

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

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

From kvn at openjdk.org  Wed Apr  3 17:38:01 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 3 Apr 2024 17:38:01 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
 [v2]
In-Reply-To: <2MTKEcGChvwWqFFuPs-5TR8GJnLwrnrgGKqdIV4NX70=.d0a707d4-5dfc-467c-992d-d410f94a7dca@github.com>
References: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
 <eMUTt2ic_OBuS168USvarGBRDCquzLb9AxrSpog1TZw=.d9ae808b-ed03-4971-bd13-db48794a1024@github.com>
 <2MTKEcGChvwWqFFuPs-5TR8GJnLwrnrgGKqdIV4NX70=.d0a707d4-5dfc-467c-992d-d410f94a7dca@github.com>
Message-ID: <T6RrkmW6BhQbPekt4q1p0SgspZS5SjR_4fGtu36E0f8=.5d406e4a-8c9c-4bff-9bf8-06fcd0e5b804@github.com>

On Wed, 3 Apr 2024 15:30:00 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed not_used state of nmethod
>
> src/hotspot/share/compiler/compileBroker.cpp line 1379:
> 
>> 1377:   if (osr_bci == InvocationEntryBci) {
>> 1378:     // standard compilation
>> 1379:     nmethod* method_code = method->code();
> 
> Isn't the `method_code->is_nmethod()` redundant now?

An other good catch! It leads me to chase all redundant `is_nmethod()` and `as_nmethod_*()` calls.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1550187397

From stefank at openjdk.org  Wed Apr  3 17:53:01 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 3 Apr 2024 17:53:01 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
 [v2]
In-Reply-To: <XLp_PiTfgwtq8j7xWRuhEPSChBsUcBYgkzrJbHpG1nU=.b29ceb12-830e-43e8-ab9e-d587c6dffd03@github.com>
References: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
 <eMUTt2ic_OBuS168USvarGBRDCquzLb9AxrSpog1TZw=.d9ae808b-ed03-4971-bd13-db48794a1024@github.com>
 <2MTKEcGChvwWqFFuPs-5TR8GJnLwrnrgGKqdIV4NX70=.d0a707d4-5dfc-467c-992d-d410f94a7dca@github.com>
 <XLp_PiTfgwtq8j7xWRuhEPSChBsUcBYgkzrJbHpG1nU=.b29ceb12-830e-43e8-ab9e-d587c6dffd03@github.com>
Message-ID: <5V3m6SFRs8kib1w_Oyyrvr-Yu904MuuPQglr-uei_So=.60542853-0800-4113-b4f0-57d328c5d866@github.com>

On Wed, 3 Apr 2024 16:29:03 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> src/hotspot/share/code/codeBlob.hpp line 409:
>> 
>>> 407: 
>>> 408:   // GC/Verification support
>>> 409:   virtual void preserve_callee_argument_oops(frame fr, const RegisterMap *reg_map, OopClosure* f) override { /* nothing to do */ }
>> 
>> In the GC code we usually have either virtual OR override, but not both. Could we skip `virtual` here? Or does the compiler code usually use both?
>
> No special rules here. I simply want to see all `virtual` methods explicitly and `override` is required by C++.
> I would like to keep it this way in these changes. I am investigating possibility to convert all these virtual methods to normal one to remove virtual table and virtual pointer (8 bytes) from CodeBlob class.

`override` is not required by C++. You do however mark all virtual methods with `override` if any of the functions are marked with `override`. I think it would be good to have a HotSpot code style discussion about this (but not in this RFE).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1550206804

From stefank at openjdk.org  Wed Apr  3 17:59:09 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 3 Apr 2024 17:59:09 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
 [v2]
In-Reply-To: <krSXrZzWLlgmaN_nvIgBhdbR75PQqpRcU3H4EBCdtP4=.b378adba-bff1-424f-b07d-d80c641e6608@github.com>
References: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
 <eMUTt2ic_OBuS168USvarGBRDCquzLb9AxrSpog1TZw=.d9ae808b-ed03-4971-bd13-db48794a1024@github.com>
 <2MTKEcGChvwWqFFuPs-5TR8GJnLwrnrgGKqdIV4NX70=.d0a707d4-5dfc-467c-992d-d410f94a7dca@github.com>
 <krSXrZzWLlgmaN_nvIgBhdbR75PQqpRcU3H4EBCdtP4=.b378adba-bff1-424f-b07d-d80c641e6608@github.com>
Message-ID: <mtLiuPqDagi21lvXlRjGpoLdxbEYEDPd8fgN06a0qB8=.ab0137a7-de30-49a2-b9a2-477b24454873@github.com>

On Wed, 3 Apr 2024 16:38:13 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> src/hotspot/share/code/codeCache.cpp line 1009:
>> 
>>> 1007: int CodeCache::nmethod_count() {
>>> 1008:   int count = 0;
>>> 1009:   for (GrowableArrayIterator<CodeHeap*> heap = _nmethod_heaps->begin(); heap != _nmethod_heaps->end(); ++heap) {
>> 
>> Is there a reason why FOR_ALL_NMETHOD_HEAPS wasn't good fit here? I'm wondering since the similar `CodeCache::blob_count()` still uses one of these macros.
>
> No,  `CodeCache::blob_count()` uses different macro `FOR_ALL_HEAPS(heap)` because it looks for all code blobs, not only nmethods.
> 
> `CodeCache::nmethod_count()` is the only place where `FOR_ALL_NMETHOD_HEAPS ` was used. So I decided to remove the macro.

I didn't say that blob_count used `FOR_ALL_NMETHODS_HEAP`. I wrote "one of these macros". I still think this adds an inconsistency to the code that I don't think is beneficial.

With that said, can't this be written as:

for (CodeHeap* heap : *_nmethod_heaps) {


Maybe yet another opportunity for cleanups.

>> src/hotspot/share/code/nmethod.cpp line 812:
>> 
>>> 810:     // By calling this nmethod entry barrier, it plays along and acts
>>> 811:     // like any other nmethod found on the stack of a thread (fewer surprises).
>>> 812:     nmethod* nm = as_nmethod_or_null();
>> 
>> Calling as_nmethod_or_null() from within functions in the nmethod class is suspicious. Shouldn't all such usages be removed? (I'm fine with doing that as a separate change)
>
> Good catch! The code was moved from CompiledMethod where it made sense but now it is not needed. Here the change I will make:
> 
>      // like any other nmethod found on the stack of a thread (fewer surprises).
> -    nmethod* nm = as_nmethod_or_null();
> -    if (nm != nullptr && bs_nm->is_armed(nm)) {
> +    nmethod* nm = this;
> +    if (bs_nm->is_armed(nm)) {
>        bool alive = bs_nm->nmethod_entry_barrier(nm);

Sounds good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1550216628
PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1550217712

From kvn at openjdk.org  Wed Apr  3 18:20:01 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 3 Apr 2024 18:20:01 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
 [v2]
In-Reply-To: <2MTKEcGChvwWqFFuPs-5TR8GJnLwrnrgGKqdIV4NX70=.d0a707d4-5dfc-467c-992d-d410f94a7dca@github.com>
References: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
 <eMUTt2ic_OBuS168USvarGBRDCquzLb9AxrSpog1TZw=.d9ae808b-ed03-4971-bd13-db48794a1024@github.com>
 <2MTKEcGChvwWqFFuPs-5TR8GJnLwrnrgGKqdIV4NX70=.d0a707d4-5dfc-467c-992d-d410f94a7dca@github.com>
Message-ID: <om30iD1Xl17sMGyyPunnpH_FYnBNSgmV6xzM80Q1oYI=.9e35b1dc-c0d6-4047-8a5a-2979c43810e1@github.com>

On Wed, 3 Apr 2024 15:49:00 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed not_used state of nmethod
>
> src/hotspot/share/runtime/frame.cpp line 208:
> 
>> 206: address frame::raw_pc() const {
>> 207:   if (is_deoptimized_frame()) {
>> 208:     nmethod* nm = cb()->as_nmethod_or_null();
> 
> Prexisting: It's weird that this code is using the `_or_null()` version when the code below does not null check the returned value.

Before [JDK-6921352](https://bugs.openjdk.org/browse/JDK-6921352) it was:

  return ((nmethod*) cb())->deopt_handler_begin() - pc_return_offset;


I will add assert with check for null. We definitely expect here only nmethod.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1550243895

From amenkov at openjdk.org  Wed Apr  3 18:31:09 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 3 Apr 2024 18:31:09 GMT
Subject: RFR: 8313332: Simplify lazy jmethodID cache in InstanceKlass [v2]
In-Reply-To: <wvi9xtVpx60MtuF-E-sRNlo_oFPHkxQwkieshGJ4m8Q=.462eb904-91a1-4188-ba6f-ed49bbf7b0ec@github.com>
References: <OnCG3ISfuvt7bIZaKL5fV8PTaZe8KWs56IWc0XdeoYo=.9d61355a-a4fe-4f6c-9a12-805a9f1febc5@github.com>
 <wvi9xtVpx60MtuF-E-sRNlo_oFPHkxQwkieshGJ4m8Q=.462eb904-91a1-4188-ba6f-ed49bbf7b0ec@github.com>
Message-ID: <MVVpB-wM0J8x9K2o3Ezl_B74g84bERf8dadqg5fmE3U=.42716e04-4f54-4142-b811-6bc5c115c625@github.com>

On Wed, 3 Apr 2024 13:25:36 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change simplifies the code that grows the jmethodID cache in InstanceKlass.  Instead of lazily, when there's a rare request for a jmethodID for an obsolete method, the jmethodID cache is grown during the RedefineClasses safepoint.  The InstanceKlass's jmethodID cache is lazily allocated when there's a jmethodID allocated, so not every InstanceKlass has a cache, but the growth now only happens in a safepoint.  This code will become racy with the potential change for deallocating jmethodIDs.
>> 
>> Tested with tier1-4, vmTestbase/nsk/jvmti java/lang/instrument tests (in case they're not in tier1-4).
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactoring suggested by Serguei.

Still looks good

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

Marked as reviewed by amenkov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18549#pullrequestreview-1977650540

From kvn at openjdk.org  Wed Apr  3 18:50:10 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 3 Apr 2024 18:50:10 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
 [v2]
In-Reply-To: <2MTKEcGChvwWqFFuPs-5TR8GJnLwrnrgGKqdIV4NX70=.d0a707d4-5dfc-467c-992d-d410f94a7dca@github.com>
References: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
 <eMUTt2ic_OBuS168USvarGBRDCquzLb9AxrSpog1TZw=.d9ae808b-ed03-4971-bd13-db48794a1024@github.com>
 <2MTKEcGChvwWqFFuPs-5TR8GJnLwrnrgGKqdIV4NX70=.d0a707d4-5dfc-467c-992d-d410f94a7dca@github.com>
Message-ID: <VBPGA16tOGTIOxwdSD4rN7S24OXwI4EN4dMK6ug13g0=.3a3ff6c6-15f0-473e-bff2-88a6dc70bcbb@github.com>

On Wed, 3 Apr 2024 15:35:49 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed not_used state of nmethod
>
> src/hotspot/share/gc/x/xUnload.cpp line 78:
> 
>> 76: class XIsUnloadingBehaviour : public IsUnloadingBehaviour {
>> 77: public:
>> 78:   virtual bool has_dead_oop(nmethod* method) const {
> 
> This now takes an `nmethod` argument, but still calls as_nmethod(). I think that should be removed from this, and all similar functions here in the GC code. If you want, I can do that as a follow-up RFE.

I decided to fix it in these changes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1550285238

From kvn at openjdk.org  Wed Apr  3 18:55:00 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 3 Apr 2024 18:55:00 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
 [v2]
In-Reply-To: <2MTKEcGChvwWqFFuPs-5TR8GJnLwrnrgGKqdIV4NX70=.d0a707d4-5dfc-467c-992d-d410f94a7dca@github.com>
References: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
 <eMUTt2ic_OBuS168USvarGBRDCquzLb9AxrSpog1TZw=.d9ae808b-ed03-4971-bd13-db48794a1024@github.com>
 <2MTKEcGChvwWqFFuPs-5TR8GJnLwrnrgGKqdIV4NX70=.d0a707d4-5dfc-467c-992d-d410f94a7dca@github.com>
Message-ID: <FTJNC_vTQA0djakJ_JFp-Q1h7byHju5jHlcmcxltmhM=.af2f0076-0804-4db1-b2ec-3ae6f5b5e630@github.com>

On Wed, 3 Apr 2024 16:00:01 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed not_used state of nmethod
>
> Nice!
> 
> We've wanted to clean up some interfaces between the CodeCache and the GC code by using nmethod closures instead of CodeBlob closures. This change (and the Sweeper removal) makes it possible to do those cleanups.
> 
> I've made a superficial pass over the patch to and left a few comments. Most of those comments are things that would be nice to fix, but could also be left as follow-up RFEs (if they are deemed to be worthy ideas to pursue).

Thank you, @stefank, for great review. I addressed all your comments locally and with run testing in mach5 before pushing it.

Except your suggestion about `find_blob_not_null()` - should be separate RFE.
The same for suggestion "GC interfaces to work directly against nmethod instead of CodeBlob".

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

PR Comment: https://git.openjdk.org/jdk/pull/18554#issuecomment-2035354740

From kvn at openjdk.org  Wed Apr  3 19:32:59 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 3 Apr 2024 19:32:59 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
 [v2]
In-Reply-To: <eMUTt2ic_OBuS168USvarGBRDCquzLb9AxrSpog1TZw=.d9ae808b-ed03-4971-bd13-db48794a1024@github.com>
References: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
 <eMUTt2ic_OBuS168USvarGBRDCquzLb9AxrSpog1TZw=.d9ae808b-ed03-4971-bd13-db48794a1024@github.com>
Message-ID: <jIu9pS_jI5cDQY5iDE_t6P7DHvdux6mDeNib5mWRqDE=.8b15297a-8b1e-4cd6-a292-10969394ff26@github.com>

On Mon, 1 Apr 2024 21:07:31 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Revert [JDK-8152664](https://bugs.openjdk.org/browse/JDK-8152664) RFE [changes](https://github.com/openjdk/jdk/commit/b853eb7f5ca24eeeda18acbb14287f706499c365) which was used for AOT [JEP 295](https://openjdk.org/jeps/295) implementation in JDK 9. The code was left in HotSpot assuming it will help in a future. But during work on Leyden we decided to not use it. In Leyden cached compiled code will be restored in CodeCache as normal nmethods: no need to change VM's runtime and GC code to process them.
>> 
>> I may work on optimizing `CodeBlob` and `nmethod` fields layout to reduce header size in separate changes. In these changes I did simple fields reordering to keep small (1 byte) fields together.
>> 
>> I do not see (and not expected) performance difference with these changes.
>> 
>> Tested tier1-5, xcomp, stress. Running performance testing.
>> 
>> I need help with testing on platforms which Oracle does not support.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed not_used state of nmethod

I filed RFEs:
[JDK-8329628](https://bugs.openjdk.org/browse/JDK-8329628): Additional changes after JDK-8329332
[JDK-8329629](https://bugs.openjdk.org/browse/JDK-8329629): GC interfaces should work directly against nmethod instead of CodeBlob

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

PR Comment: https://git.openjdk.org/jdk/pull/18554#issuecomment-2035421134

From kvn at openjdk.org  Wed Apr  3 19:59:01 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 3 Apr 2024 19:59:01 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
 [v2]
In-Reply-To: <5V3m6SFRs8kib1w_Oyyrvr-Yu904MuuPQglr-uei_So=.60542853-0800-4113-b4f0-57d328c5d866@github.com>
References: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
 <eMUTt2ic_OBuS168USvarGBRDCquzLb9AxrSpog1TZw=.d9ae808b-ed03-4971-bd13-db48794a1024@github.com>
 <2MTKEcGChvwWqFFuPs-5TR8GJnLwrnrgGKqdIV4NX70=.d0a707d4-5dfc-467c-992d-d410f94a7dca@github.com>
 <XLp_PiTfgwtq8j7xWRuhEPSChBsUcBYgkzrJbHpG1nU=.b29ceb12-830e-43e8-ab9e-d587c6dffd03@github.com>
 <5V3m6SFRs8kib1w_Oyyrvr-Yu904MuuPQglr-uei_So=.60542853-0800-4113-b4f0-57d328c5d866@github.com>
Message-ID: <TsLkhgOLr2NkwL1GXLkb2yq_z8rCrYEyE2MptLsiODU=.9c12c963-a742-4e0b-a27f-3d3c62b7312b@github.com>

On Wed, 3 Apr 2024 17:50:15 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> No special rules here. I simply want to see all `virtual` methods explicitly and `override` is required by C++.
>> I would like to keep it this way in these changes. I am investigating possibility to convert all these virtual methods to normal one to remove virtual table and virtual pointer (8 bytes) from CodeBlob class.
>
> `override` is not required by C++. You do however mark all virtual methods with `override` if any of the functions are marked with `override`. I think it would be good to have a HotSpot code style discussion about this (but not in this RFE).

I put `virtual/override` cleanup in CodeBlob as additional suggestion in followup RFE JDK-8329628.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1550370826

From kvn at openjdk.org  Wed Apr  3 20:03:11 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 3 Apr 2024 20:03:11 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
 [v2]
In-Reply-To: <mtLiuPqDagi21lvXlRjGpoLdxbEYEDPd8fgN06a0qB8=.ab0137a7-de30-49a2-b9a2-477b24454873@github.com>
References: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
 <eMUTt2ic_OBuS168USvarGBRDCquzLb9AxrSpog1TZw=.d9ae808b-ed03-4971-bd13-db48794a1024@github.com>
 <2MTKEcGChvwWqFFuPs-5TR8GJnLwrnrgGKqdIV4NX70=.d0a707d4-5dfc-467c-992d-d410f94a7dca@github.com>
 <krSXrZzWLlgmaN_nvIgBhdbR75PQqpRcU3H4EBCdtP4=.b378adba-bff1-424f-b07d-d80c641e6608@github.com>
 <mtLiuPqDagi21lvXlRjGpoLdxbEYEDPd8fgN06a0qB8=.ab0137a7-de30-49a2-b9a2-477b24454873@github.com>
Message-ID: <AOdJarQeO7v1yqhDaRD7jt1UAmxWs7keOOjFmT0TAlM=.b76bf8a7-00b4-4c15-9da2-fb7016cd0fde@github.com>

On Wed, 3 Apr 2024 17:55:38 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> No,  `CodeCache::blob_count()` uses different macro `FOR_ALL_HEAPS(heap)` because it looks for all code blobs, not only nmethods.
>> 
>> `CodeCache::nmethod_count()` is the only place where `FOR_ALL_NMETHOD_HEAPS ` was used. So I decided to remove the macro.
>
> I didn't say that blob_count used `FOR_ALL_NMETHODS_HEAP`. I wrote "one of these macros". I still think this adds an inconsistency to the code that I don't think is beneficial.
> 
> With that said, can't this be written as:
> 
> for (CodeHeap* heap : *_nmethod_heaps) {
> 
> 
> Maybe yet another opportunity for cleanups.

I like it and will do it in JDK-8329628.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1550378690

From cjplummer at openjdk.org  Wed Apr  3 20:34:11 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 3 Apr 2024 20:34:11 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v10]
In-Reply-To: <yAw0k8FSAAaLP-xgtm4guG3bv3T5pWAGedrQcEGKJPU=.4e64fb46-277e-4ee5-971c-c862ea9d4c54@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>
 <NM_-NsTTOGAxlIwZlSaVf2TgV3UbcbLxIRA_9gZNY0c=.3aba23e1-a875-46bc-9fa9-6e892e534be8@github.com>
 <LMtCcLS4Vmt2SN3AnXDdKTl1jAlo6Ehp4lZDGGbZxQg=.b10bd71e-fea3-48e7-9c31-4caecee18fe0@github.com>
 <jXp9C900RJWni3Vx_e8h3d1tvim1E3Vs5i53FWO8g1E=.0c0f9f2a-4c6e-42a1-ac19-227a4344f805@github.com>
 <yAw0k8FSAAaLP-xgtm4guG3bv3T5pWAGedrQcEGKJPU=.4e64fb46-277e-4ee5-971c-c862ea9d4c54@github.com>
Message-ID: <W84TZYOo1JAP1MHeDm4ZeFoNXOVhS7dHM_4NHHOLKSE=.426663e4-a13a-4e35-b139-bdd12c00da86@github.com>

On Wed, 3 Apr 2024 08:03:22 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > There's also a question of whether currently missing doc updates for HeapDumpGzipLevel should be made part of this PR
> > because it complicates back porting.
> 
> It should most likely be a separate PR (the title of this one does not match, and there are different backporting needs).

Then you end up with the same issue that this PR has with 7 docs to update (and the "descriptive" default for the jcmd). I'm not advocating one approach over the other. I'm just pointing out that either approach has it's warts, and they rooted in the changes done for this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2035525083

From amenkov at openjdk.org  Wed Apr  3 20:37:09 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 3 Apr 2024 20:37:09 GMT
Subject: RFR: JDK-8322042: HeapDumper should perform merge on the current
 thread instead of VMThread [v2]
In-Reply-To: <VRgP2qovkj_wGSndk6nnQGyIGuepx4FvkQwDpCioEPg=.185b5baa-474e-406f-a297-379552159438@github.com>
References: <4--MamzddI0M3jpWu5NG1OvvX2aOo1vTUsH0TNYmty0=.9c4f04fc-2809-427f-9109-6a2f8be3ca5a@github.com>
 <5DSzGDsLSswF0y1iWTfoq0kYpZqXPqVLgN4lItTF1EE=.2989a521-e453-41fb-89e8-3aabe478f8a8@github.com>
 <VRgP2qovkj_wGSndk6nnQGyIGuepx4FvkQwDpCioEPg=.185b5baa-474e-406f-a297-379552159438@github.com>
Message-ID: <xqaEsYS3zIdIo-vcwLA8cCDdu9H3gzIeBGsoheYhDW4=.a3b6895b-c73e-40a5-808c-257f1e9d9ece@github.com>

On Wed, 3 Apr 2024 10:09:20 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Are we saying there is never any need to perform the merge in a VM Operation? Originally (JDK-8306441) it's either done in the attach thread, or a VM operation if we are in another thread. But maybe that was just being cautious.

Correct.
Originally it was implemented for AttachListener thread only for safety (and heap dump using jcmd was point of interest).
I didn't find issues with concurrent dumping (actually with concurrent merging, dumping itself is performed in VM_HeapDumper at safepoint).

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

PR Comment: https://git.openjdk.org/jdk/pull/18571#issuecomment-2035530652

From cjplummer at openjdk.org  Wed Apr  3 20:43:10 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 3 Apr 2024 20:43:10 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v10]
In-Reply-To: <x5zxycBv-sMrSoqdYYwYE9fMw7r53sofqTigBzke24A=.3b96b8bc-40b9-4273-8696-e9a5d9b5b65e@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>
 <NM_-NsTTOGAxlIwZlSaVf2TgV3UbcbLxIRA_9gZNY0c=.3aba23e1-a875-46bc-9fa9-6e892e534be8@github.com>
 <LMtCcLS4Vmt2SN3AnXDdKTl1jAlo6Ehp4lZDGGbZxQg=.b10bd71e-fea3-48e7-9c31-4caecee18fe0@github.com>
 <jXp9C900RJWni3Vx_e8h3d1tvim1E3Vs5i53FWO8g1E=.0c0f9f2a-4c6e-42a1-ac19-227a4344f805@github.com>
 <x5zxycBv-sMrSoqdYYwYE9fMw7r53sofqTigBzke24A=.3b96b8bc-40b9-4273-8696-e9a5d9b5b65e@github.com>
Message-ID: <69TwQkDVz3kMozJGjEtldrlJ5lt0kcYfh1hCL8wfjxY=.d1e79052-0791-4e7d-8e6a-1fc68caba0cd@github.com>

On Wed, 3 Apr 2024 09:04:34 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > There's still the question of whether or not it is even appropriate to have -XX options taking the place of jcmd options.
> 
> Some people (like our cloud support colleagues and also some who commented) would like this approach, some find it not very useful. Seems there are also already other globals flags playing a role in diagnosticCommand coding (e.g. RecordDynamicDumpInfo, maybe more) so it is not completely 'new' that the jcmd commands are influenced by globals flag. Looking at just the _names_ of HeapDumpPath and also HeapDumpGzipLevel I would think that they play a role for all heap dumps and not just some.

That's a little different. For some reason (I'm not sure of the details) it was decided to not allow a dynamic dump with VM.cds unless it was explicitly enabled on the command line with the -XX:+ RecordDynamicDumpInfo option. This is different than having an jvm option that is used in place of an omitted jcmd option.

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2035541597

From cjplummer at openjdk.org  Wed Apr  3 20:47:11 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 3 Apr 2024 20:47:11 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v10]
In-Reply-To: <S5HlZ9fPPANZHjyo_ZLBOv8OKqBNO06D8obHDri9tOw=.005a650a-11b0-4347-a92e-c0c48984155a@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>
 <S5HlZ9fPPANZHjyo_ZLBOv8OKqBNO06D8obHDri9tOw=.005a650a-11b0-4347-a92e-c0c48984155a@github.com>
Message-ID: <NG9MhtJIMtfp89z3rssc7E-reYQHgyjzlGa-A8GYlu0=.9710c862-16c2-4e9f-a0bd-65b1d908ce2b@github.com>

On Wed, 3 Apr 2024 13:37:56 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Couldn't we just have an unconditional default for the GC.heap_dump `filename` option? This would simplify the documentation. E.g. we could write `If not specified, defaults to java_pid<pid>.hprof in the working directory or value configured through -XX:HeapDumpPath`

I've had similar thoughts while considering this PR. I'm not sure why currently there is no default. HeapDumpPath is not quite as simple as you document it above. It can be a filename or a directory, and when it is a directory it has its own default file naming. This should be captured in the jcmd help.

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2035550491

From kevinw at openjdk.org  Wed Apr  3 21:43:01 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 3 Apr 2024 21:43:01 GMT
Subject: RFR: JDK-8322042: HeapDumper should perform merge on the current
 thread instead of VMThread [v2]
In-Reply-To: <5DSzGDsLSswF0y1iWTfoq0kYpZqXPqVLgN4lItTF1EE=.2989a521-e453-41fb-89e8-3aabe478f8a8@github.com>
References: <4--MamzddI0M3jpWu5NG1OvvX2aOo1vTUsH0TNYmty0=.9c4f04fc-2809-427f-9109-6a2f8be3ca5a@github.com>
 <5DSzGDsLSswF0y1iWTfoq0kYpZqXPqVLgN4lItTF1EE=.2989a521-e453-41fb-89e8-3aabe478f8a8@github.com>
Message-ID: <ESjnV3CL3xXD82zMnrS35madKOXplCsHjd226pZogAo=.4feaf7ac-b18f-44d7-92c1-aafd1c186db8@github.com>

On Tue, 2 Apr 2024 21:13:33 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updated HeapDumper to always perform merge on the current thread.
>> 
>> Testing: tier1-5, all HeapDump-related tests
>>   Covered heap dumping scenarios:
>>     - `jcmd GC.heap_dump` command;
>>     - `HotSpotDiagnosticMXBean.dumpHeap()`;
>>     - `HeapDumpBeforeFullGC`, `HeapDumpAfterFullGC` VM options;
>>     - `HeapDumpOnOutOfMemoryError` VM option.
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment

Marked as reviewed by kevinw (Reviewer).

Thanks Alex, happy you've looked into that. 8-)

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

PR Review: https://git.openjdk.org/jdk/pull/18571#pullrequestreview-1978117624
PR Comment: https://git.openjdk.org/jdk/pull/18571#issuecomment-2035648620

From dcubed at openjdk.org  Wed Apr  3 22:09:11 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 3 Apr 2024 22:09:11 GMT
Subject: RFR: 8313332: Simplify lazy jmethodID cache in InstanceKlass [v2]
In-Reply-To: <wvi9xtVpx60MtuF-E-sRNlo_oFPHkxQwkieshGJ4m8Q=.462eb904-91a1-4188-ba6f-ed49bbf7b0ec@github.com>
References: <OnCG3ISfuvt7bIZaKL5fV8PTaZe8KWs56IWc0XdeoYo=.9d61355a-a4fe-4f6c-9a12-805a9f1febc5@github.com>
 <wvi9xtVpx60MtuF-E-sRNlo_oFPHkxQwkieshGJ4m8Q=.462eb904-91a1-4188-ba6f-ed49bbf7b0ec@github.com>
Message-ID: <9wpF-UcKkG-ycqj4ZmamdW7ZwPG9ymnStT555X4_5ck=.bb747b4b-621f-4275-9180-8f432685cf74@github.com>

On Wed, 3 Apr 2024 13:25:36 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change simplifies the code that grows the jmethodID cache in InstanceKlass.  Instead of lazily, when there's a rare request for a jmethodID for an obsolete method, the jmethodID cache is grown during the RedefineClasses safepoint.  The InstanceKlass's jmethodID cache is lazily allocated when there's a jmethodID allocated, so not every InstanceKlass has a cache, but the growth now only happens in a safepoint.  This code will become racy with the potential change for deallocating jmethodIDs.
>> 
>> Tested with tier1-4, vmTestbase/nsk/jvmti java/lang/instrument tests (in case they're not in tier1-4).
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactoring suggested by Serguei.

Okay I've crawled thru the changes twice and I went back thru
the bug history for this code and added some notes and links
to the bug ID.

Modulo the nits that I flagged, I think the changes are fine. Making
cache growth only happen in the RedefineClasses safepoint is
definite improvement.

I see that you've run JVM/TI and JLI tests. You should also run JDI
tests. Basically for a low level fix like this that affects JVM/TI, you
should run Mach5 Tier[1-6].

src/hotspot/share/oops/instanceKlass.cpp line 2272:

> 2270: jmethodID InstanceKlass::update_jmethod_id(jmethodID* jmeths, Method* method, int idnum) {
> 2271:   if (method->is_old() && !method->is_obsolete()) {
> 2272:     // If the method passed in is old (but not obsolete), use the current version

nit: should end with a period.

src/hotspot/share/oops/instanceKlass.cpp line 2277:

> 2275:   }
> 2276:   jmethodID new_id = Method::make_jmethod_id(class_loader_data(), method);
> 2277:   Atomic::release_store(&jmeths[idnum+1], new_id);

nit: spaces around operator `+`

src/hotspot/share/oops/instanceKlass.cpp line 2304:

> 2302:   //
> 2303:   // If the RedefineClasses() API has been used, then this cache grows
> 2304:   // in the redefinition safepoint.

Much easier to reason about. Thanks for simplifying it.

src/hotspot/share/oops/instanceKlass.cpp line 2314:

> 2312:       assert(size > (size_t)idnum, "should already have space");
> 2313:       jmeths = NEW_C_HEAP_ARRAY(jmethodID, size+1, mtClass);
> 2314:       memset(jmeths, 0, (size+1)*sizeof(jmethodID));

nit: spaces around operator `+` (two places)
nit: spaces around operator `*`

src/hotspot/share/oops/instanceKlass.cpp line 2325:

> 2323:   }
> 2324: 
> 2325:   jmethodID id = Atomic::load_acquire(&jmeths[idnum+1]);

nit: spaces around operator `+`

src/hotspot/share/oops/instanceKlass.cpp line 2328:

> 2326:   if (id == nullptr) {
> 2327:     MutexLocker ml(JmethodIdCreation_lock, Mutex::_no_safepoint_check_flag);
> 2328:     id = jmeths[idnum+1];

nit: spaces around operator `+`

src/hotspot/share/oops/instanceKlass.cpp line 2343:

> 2341:     size_t size = idnum_allocated_count();
> 2342:     size_t old_size = (size_t)cache[0];
> 2343:     if (old_size < size+1) {

nit: spaces around operator `+`

src/hotspot/share/oops/instanceKlass.cpp line 2344:

> 2342:     size_t old_size = (size_t)cache[0];
> 2343:     if (old_size < size+1) {
> 2344:       // allocate a larger one and copy entries to the new one.

nit typo: s/allocate/Allocate/

src/hotspot/share/oops/instanceKlass.cpp line 2345:

> 2343:     if (old_size < size+1) {
> 2344:       // allocate a larger one and copy entries to the new one.
> 2345:       // They've already been updated to point to new methods where applicable (ie. not obsolete)

nit typo: s/ie./i.e.,/
Please add a period at the end of the sentence.

src/hotspot/share/oops/instanceKlass.cpp line 2347:

> 2345:       // They've already been updated to point to new methods where applicable (ie. not obsolete)
> 2346:       jmethodID* new_cache = NEW_C_HEAP_ARRAY(jmethodID, size+1, mtClass);
> 2347:       memset(new_cache, 0, (size+1)*sizeof(jmethodID));

nit: spaces around operator `+` (two places)
nit: spaces around operator `*`

src/hotspot/share/oops/instanceKlass.cpp line 2348:

> 2346:       jmethodID* new_cache = NEW_C_HEAP_ARRAY(jmethodID, size+1, mtClass);
> 2347:       memset(new_cache, 0, (size+1)*sizeof(jmethodID));
> 2348:       // cache size is stored in element[0], other elements offset by one

nit typo: s/cache/Cache/
Please add a period at the end.

src/hotspot/share/oops/instanceKlass.cpp line 2384:

> 2382:   int idnum = method->method_idnum();
> 2383:   jmethodID* jmeths = methods_jmethod_ids_acquire();
> 2384:   return (jmeths != nullptr) ? jmeths[idnum+1] : nullptr;

nit: spaces around operator `+`

src/hotspot/share/oops/method.cpp line 2200:

> 2198: 
> 2199:   ResourceMark rm;
> 2200:   log_info(jmethod)("Creating jmethodID for Method %s", m->external_name());

Hmmm... will this be too noisy for `info` level?

src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4353:

> 4351:   the_class->itable().initialize_itable();
> 4352: 
> 4353:   // Update jmethodID cache if present

Nit: should end with period.

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

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18549#pullrequestreview-1977965153
PR Review Comment: https://git.openjdk.org/jdk/pull/18549#discussion_r1550473408
PR Review Comment: https://git.openjdk.org/jdk/pull/18549#discussion_r1550476292
PR Review Comment: https://git.openjdk.org/jdk/pull/18549#discussion_r1550488626
PR Review Comment: https://git.openjdk.org/jdk/pull/18549#discussion_r1550492405
PR Review Comment: https://git.openjdk.org/jdk/pull/18549#discussion_r1550491163
PR Review Comment: https://git.openjdk.org/jdk/pull/18549#discussion_r1550492871
PR Review Comment: https://git.openjdk.org/jdk/pull/18549#discussion_r1550499076
PR Review Comment: https://git.openjdk.org/jdk/pull/18549#discussion_r1550499498
PR Review Comment: https://git.openjdk.org/jdk/pull/18549#discussion_r1550500350
PR Review Comment: https://git.openjdk.org/jdk/pull/18549#discussion_r1550501547
PR Review Comment: https://git.openjdk.org/jdk/pull/18549#discussion_r1550503608
PR Review Comment: https://git.openjdk.org/jdk/pull/18549#discussion_r1550505968
PR Review Comment: https://git.openjdk.org/jdk/pull/18549#discussion_r1550458475
PR Review Comment: https://git.openjdk.org/jdk/pull/18549#discussion_r1550449234

From coleenp at openjdk.org  Wed Apr  3 23:05:24 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 3 Apr 2024 23:05:24 GMT
Subject: RFR: 8313332: Simplify lazy jmethodID cache in InstanceKlass [v3]
In-Reply-To: <OnCG3ISfuvt7bIZaKL5fV8PTaZe8KWs56IWc0XdeoYo=.9d61355a-a4fe-4f6c-9a12-805a9f1febc5@github.com>
References: <OnCG3ISfuvt7bIZaKL5fV8PTaZe8KWs56IWc0XdeoYo=.9d61355a-a4fe-4f6c-9a12-805a9f1febc5@github.com>
Message-ID: <IjpensOJbD0XWYOx6nehioXNwXYSMxIOBG3Cup7jgBE=.cb1fed50-0198-4c97-b823-5806e0b6d27f@github.com>

> This change simplifies the code that grows the jmethodID cache in InstanceKlass.  Instead of lazily, when there's a rare request for a jmethodID for an obsolete method, the jmethodID cache is grown during the RedefineClasses safepoint.  The InstanceKlass's jmethodID cache is lazily allocated when there's a jmethodID allocated, so not every InstanceKlass has a cache, but the growth now only happens in a safepoint.  This code will become racy with the potential change for deallocating jmethodIDs.
> 
> Tested with tier1-4, vmTestbase/nsk/jvmti java/lang/instrument tests (in case they're not in tier1-4).

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix spacing and punctuation.  make log_info into log_debug.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18549/files
  - new: https://git.openjdk.org/jdk/pull/18549/files/6576d14d..26bd82d3

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

  Stats: 13 lines in 3 files changed: 0 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/18549.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18549/head:pull/18549

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

From coleenp at openjdk.org  Wed Apr  3 23:05:24 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 3 Apr 2024 23:05:24 GMT
Subject: RFR: 8313332: Simplify lazy jmethodID cache in InstanceKlass [v2]
In-Reply-To: <wvi9xtVpx60MtuF-E-sRNlo_oFPHkxQwkieshGJ4m8Q=.462eb904-91a1-4188-ba6f-ed49bbf7b0ec@github.com>
References: <OnCG3ISfuvt7bIZaKL5fV8PTaZe8KWs56IWc0XdeoYo=.9d61355a-a4fe-4f6c-9a12-805a9f1febc5@github.com>
 <wvi9xtVpx60MtuF-E-sRNlo_oFPHkxQwkieshGJ4m8Q=.462eb904-91a1-4188-ba6f-ed49bbf7b0ec@github.com>
Message-ID: <rN5ZM4pL1MwpAt6aC4GQ-euQoAjftfyPw25W2kqvgX8=.81211c9d-94b6-474a-adaa-c818f1f05678@github.com>

On Wed, 3 Apr 2024 13:25:36 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change simplifies the code that grows the jmethodID cache in InstanceKlass.  Instead of lazily, when there's a rare request for a jmethodID for an obsolete method, the jmethodID cache is grown during the RedefineClasses safepoint.  The InstanceKlass's jmethodID cache is lazily allocated when there's a jmethodID allocated, so not every InstanceKlass has a cache, but the growth now only happens in a safepoint.  This code will become racy with the potential change for deallocating jmethodIDs.
>> 
>> Tested with tier1-4, vmTestbase/nsk/jvmti java/lang/instrument tests (in case they're not in tier1-4).
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactoring suggested by Serguei.

Thanks for reviewing this Dan.  I've fixed the nits you pointed out.

I ran tier1-4 which includes JDI tests, but I'll run 5, 6 tonight.

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

PR Review: https://git.openjdk.org/jdk/pull/18549#pullrequestreview-1978241218
PR Comment: https://git.openjdk.org/jdk/pull/18549#issuecomment-2035752492

From coleenp at openjdk.org  Wed Apr  3 23:05:24 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 3 Apr 2024 23:05:24 GMT
Subject: RFR: 8313332: Simplify lazy jmethodID cache in InstanceKlass [v2]
In-Reply-To: <9wpF-UcKkG-ycqj4ZmamdW7ZwPG9ymnStT555X4_5ck=.bb747b4b-621f-4275-9180-8f432685cf74@github.com>
References: <OnCG3ISfuvt7bIZaKL5fV8PTaZe8KWs56IWc0XdeoYo=.9d61355a-a4fe-4f6c-9a12-805a9f1febc5@github.com>
 <wvi9xtVpx60MtuF-E-sRNlo_oFPHkxQwkieshGJ4m8Q=.462eb904-91a1-4188-ba6f-ed49bbf7b0ec@github.com>
 <9wpF-UcKkG-ycqj4ZmamdW7ZwPG9ymnStT555X4_5ck=.bb747b4b-621f-4275-9180-8f432685cf74@github.com>
Message-ID: <NzbxOuiF0PlxRnNdEG_QKeJ6vx_2LpivurJcxuDDIQc=.be4be847-beff-4f3c-8599-86f9973cbb82@github.com>

On Wed, 3 Apr 2024 20:46:55 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactoring suggested by Serguei.
>
> src/hotspot/share/oops/method.cpp line 2200:
> 
>> 2198: 
>> 2199:   ResourceMark rm;
>> 2200:   log_info(jmethod)("Creating jmethodID for Method %s", m->external_name());
> 
> Hmmm... will this be too noisy for `info` level?

I forget that there's a default where -Xlog nothing will print all the info level messages.  I changed it to debug.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18549#discussion_r1550615588

From dcubed at openjdk.org  Wed Apr  3 23:55:01 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 3 Apr 2024 23:55:01 GMT
Subject: RFR: 8313332: Simplify lazy jmethodID cache in InstanceKlass [v3]
In-Reply-To: <IjpensOJbD0XWYOx6nehioXNwXYSMxIOBG3Cup7jgBE=.cb1fed50-0198-4c97-b823-5806e0b6d27f@github.com>
References: <OnCG3ISfuvt7bIZaKL5fV8PTaZe8KWs56IWc0XdeoYo=.9d61355a-a4fe-4f6c-9a12-805a9f1febc5@github.com>
 <IjpensOJbD0XWYOx6nehioXNwXYSMxIOBG3Cup7jgBE=.cb1fed50-0198-4c97-b823-5806e0b6d27f@github.com>
Message-ID: <lgyjewCQl68pBdFd-W_z51ez18WlfFXB6VYk5B4ESto=.0be28b82-e809-4490-b701-2701484c8837@github.com>

On Wed, 3 Apr 2024 23:05:24 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change simplifies the code that grows the jmethodID cache in InstanceKlass.  Instead of lazily, when there's a rare request for a jmethodID for an obsolete method, the jmethodID cache is grown during the RedefineClasses safepoint.  The InstanceKlass's jmethodID cache is lazily allocated when there's a jmethodID allocated, so not every InstanceKlass has a cache, but the growth now only happens in a safepoint.  This code will become racy with the potential change for deallocating jmethodIDs.
>> 
>> Tested with tier1-4, vmTestbase/nsk/jvmti java/lang/instrument tests (in case they're not in tier1-4).
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix spacing and punctuation.  make log_info into log_debug.

Thanks for the fixes. There are a couple that you missed.

src/hotspot/share/oops/instanceKlass.cpp line 2313:

> 2311:       size_t size = idnum_allocated_count();
> 2312:       assert(size > (size_t)idnum, "should already have space");
> 2313:       jmeths = NEW_C_HEAP_ARRAY(jmethodID, size+1, mtClass);

nit: spaces around operator `+`

src/hotspot/share/oops/instanceKlass.cpp line 2346:

> 2344:       // Allocate a larger one and copy entries to the new one.
> 2345:       // They've already been updated to point to new methods where applicable (i.e., not obsolete).
> 2346:       jmethodID* new_cache = NEW_C_HEAP_ARRAY(jmethodID, size+1, mtClass);

nit: spaces around operator `+`

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

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18549#pullrequestreview-1978305784
PR Review Comment: https://git.openjdk.org/jdk/pull/18549#discussion_r1550653423
PR Review Comment: https://git.openjdk.org/jdk/pull/18549#discussion_r1550653504

From kvn at openjdk.org  Thu Apr  4 00:05:20 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 4 Apr 2024 00:05:20 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
 [v3]
In-Reply-To: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
References: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
Message-ID: <2sg6I-HBI12rc2LoWYX-A1S5vfMfDyj_5xoykANrZ8g=.6d0e5daa-30e4-45df-990e-c45b63477182@github.com>

> Revert [JDK-8152664](https://bugs.openjdk.org/browse/JDK-8152664) RFE [changes](https://github.com/openjdk/jdk/commit/b853eb7f5ca24eeeda18acbb14287f706499c365) which was used for AOT [JEP 295](https://openjdk.org/jeps/295) implementation in JDK 9. The code was left in HotSpot assuming it will help in a future. But during work on Leyden we decided to not use it. In Leyden cached compiled code will be restored in CodeCache as normal nmethods: no need to change VM's runtime and GC code to process them.
> 
> I may work on optimizing `CodeBlob` and `nmethod` fields layout to reduce header size in separate changes. In these changes I did simple fields reordering to keep small (1 byte) fields together.
> 
> I do not see (and not expected) performance difference with these changes.
> 
> Tested tier1-5, xcomp, stress. Running performance testing.
> 
> I need help with testing on platforms which Oracle does not support.

Vladimir Kozlov 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 five additional commits since the last revision:

 - Address comments
 - Merge branch 'master' into 8329332
 - Removed not_used state of nmethod
 - remove trailing whitespace
 - 8329332: Remove CompiledMethod and CodeBlobLayout classes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18554/files
  - new: https://git.openjdk.org/jdk/pull/18554/files/246ff68a..33768fb2

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

  Stats: 9283 lines in 197 files changed: 3058 ins; 4514 del; 1711 mod
  Patch: https://git.openjdk.org/jdk/pull/18554.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18554/head:pull/18554

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

From coleenp at openjdk.org  Thu Apr  4 00:07:34 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 4 Apr 2024 00:07:34 GMT
Subject: RFR: 8313332: Simplify lazy jmethodID cache in InstanceKlass [v4]
In-Reply-To: <OnCG3ISfuvt7bIZaKL5fV8PTaZe8KWs56IWc0XdeoYo=.9d61355a-a4fe-4f6c-9a12-805a9f1febc5@github.com>
References: <OnCG3ISfuvt7bIZaKL5fV8PTaZe8KWs56IWc0XdeoYo=.9d61355a-a4fe-4f6c-9a12-805a9f1febc5@github.com>
Message-ID: <Aj-RC_ZNp-5o-36PvFr4wum7e3iyr2hcZtkhI6P7VGY=.fa1fed00-ddac-4dd1-8b21-36c2675598b3@github.com>

> This change simplifies the code that grows the jmethodID cache in InstanceKlass.  Instead of lazily, when there's a rare request for a jmethodID for an obsolete method, the jmethodID cache is grown during the RedefineClasses safepoint.  The InstanceKlass's jmethodID cache is lazily allocated when there's a jmethodID allocated, so not every InstanceKlass has a cache, but the growth now only happens in a safepoint.  This code will become racy with the potential change for deallocating jmethodIDs.
> 
> Tested with tier1-4, vmTestbase/nsk/jvmti java/lang/instrument tests (in case they're not in tier1-4).

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Two more.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18549/files
  - new: https://git.openjdk.org/jdk/pull/18549/files/26bd82d3..aab60e28

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

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

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

From coleenp at openjdk.org  Thu Apr  4 00:07:34 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 4 Apr 2024 00:07:34 GMT
Subject: RFR: 8313332: Simplify lazy jmethodID cache in InstanceKlass [v3]
In-Reply-To: <lgyjewCQl68pBdFd-W_z51ez18WlfFXB6VYk5B4ESto=.0be28b82-e809-4490-b701-2701484c8837@github.com>
References: <OnCG3ISfuvt7bIZaKL5fV8PTaZe8KWs56IWc0XdeoYo=.9d61355a-a4fe-4f6c-9a12-805a9f1febc5@github.com>
 <IjpensOJbD0XWYOx6nehioXNwXYSMxIOBG3Cup7jgBE=.cb1fed50-0198-4c97-b823-5806e0b6d27f@github.com>
 <lgyjewCQl68pBdFd-W_z51ez18WlfFXB6VYk5B4ESto=.0be28b82-e809-4490-b701-2701484c8837@github.com>
Message-ID: <DZcpL1PA4ScJD8jgj-NYE2r6CkbK5tRmP2dulRKZJwc=.918e02bb-50b5-4d46-81b0-51f66d5d0a45@github.com>

On Wed, 3 Apr 2024 23:50:47 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix spacing and punctuation.  make log_info into log_debug.
>
> src/hotspot/share/oops/instanceKlass.cpp line 2313:
> 
>> 2311:       size_t size = idnum_allocated_count();
>> 2312:       assert(size > (size_t)idnum, "should already have space");
>> 2313:       jmeths = NEW_C_HEAP_ARRAY(jmethodID, size+1, mtClass);
> 
> nit: spaces around operator `+`

Got them.  The good thing about the smaller function is it's easier to find these.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18549#discussion_r1550659977

From kvn at openjdk.org  Thu Apr  4 00:40:03 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 4 Apr 2024 00:40:03 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
 [v3]
In-Reply-To: <2sg6I-HBI12rc2LoWYX-A1S5vfMfDyj_5xoykANrZ8g=.6d0e5daa-30e4-45df-990e-c45b63477182@github.com>
References: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
 <2sg6I-HBI12rc2LoWYX-A1S5vfMfDyj_5xoykANrZ8g=.6d0e5daa-30e4-45df-990e-c45b63477182@github.com>
Message-ID: <ksNybPkksl9L8hZALhOyEh2yGV5n2DlQ0W_cUyXAtdc=.5be23eee-dcf9-4cdb-a153-e5a9bec4fd01@github.com>

On Thu, 4 Apr 2024 00:05:20 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Revert [JDK-8152664](https://bugs.openjdk.org/browse/JDK-8152664) RFE [changes](https://github.com/openjdk/jdk/commit/b853eb7f5ca24eeeda18acbb14287f706499c365) which was used for AOT [JEP 295](https://openjdk.org/jeps/295) implementation in JDK 9. The code was left in HotSpot assuming it will help in a future. But during work on Leyden we decided to not use it. In Leyden cached compiled code will be restored in CodeCache as normal nmethods: no need to change VM's runtime and GC code to process them.
>> 
>> I may work on optimizing `CodeBlob` and `nmethod` fields layout to reduce header size in separate changes. In these changes I did simple fields reordering to keep small (1 byte) fields together.
>> 
>> I do not see (and not expected) performance difference with these changes.
>> 
>> Tested tier1-5, xcomp, stress. Running performance testing.
>> 
>> I need help with testing on platforms which Oracle does not support.
>
> Vladimir Kozlov 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 five additional commits since the last revision:
> 
>  - Address comments
>  - Merge branch 'master' into 8329332
>  - Removed not_used state of nmethod
>  - remove trailing whitespace
>  - 8329332: Remove CompiledMethod and CodeBlobLayout classes

GHA `linux-x64-hs-minimal` failure is not related to changes:

2024-04-04T00:07:46.9654262Z ##[warning]Failed to download action 'https://api.github.com/repos/actions/github-script/tarball/60a0d83039c74a4aee543508d2ffcb1c3799cdea'. Error: The request was canceled due to the configured HttpClient.Timeout of 100 seconds elapsing.
2024-04-04T00:07:46.9656929Z ##[warning]Back off 22.252 seconds before retry.
2024-04-04T00:08:52.1252710Z ##[error]The SSL connection could not be established, see inner exception.

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

PR Comment: https://git.openjdk.org/jdk/pull/18554#issuecomment-2035859221

From aboldtch at openjdk.org  Thu Apr  4 06:57:03 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 4 Apr 2024 06:57:03 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
 [v3]
In-Reply-To: <2sg6I-HBI12rc2LoWYX-A1S5vfMfDyj_5xoykANrZ8g=.6d0e5daa-30e4-45df-990e-c45b63477182@github.com>
References: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
 <2sg6I-HBI12rc2LoWYX-A1S5vfMfDyj_5xoykANrZ8g=.6d0e5daa-30e4-45df-990e-c45b63477182@github.com>
Message-ID: <5Mj_wuhYdBmtFIJAD0qrBMlrX1TmTzutO7hLN--mvec=.913fd656-7155-4744-ae8a-0d5266e76cca@github.com>

On Thu, 4 Apr 2024 00:05:20 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Revert [JDK-8152664](https://bugs.openjdk.org/browse/JDK-8152664) RFE [changes](https://github.com/openjdk/jdk/commit/b853eb7f5ca24eeeda18acbb14287f706499c365) which was used for AOT [JEP 295](https://openjdk.org/jeps/295) implementation in JDK 9. The code was left in HotSpot assuming it will help in a future. But during work on Leyden we decided to not use it. In Leyden cached compiled code will be restored in CodeCache as normal nmethods: no need to change VM's runtime and GC code to process them.
>> 
>> I may work on optimizing `CodeBlob` and `nmethod` fields layout to reduce header size in separate changes. In these changes I did simple fields reordering to keep small (1 byte) fields together.
>> 
>> I do not see (and not expected) performance difference with these changes.
>> 
>> Tested tier1-5, xcomp, stress. Running performance testing.
>> 
>> I need help with testing on platforms which Oracle does not support.
>
> Vladimir Kozlov 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 five additional commits since the last revision:
> 
>  - Address comments
>  - Merge branch 'master' into 8329332
>  - Removed not_used state of nmethod
>  - remove trailing whitespace
>  - 8329332: Remove CompiledMethod and CodeBlobLayout classes

There is a stale comment in `test/jdk/com/sun/jdi/EATests.java:1288`


-// (See CompiledMethod::is_at_poll_return())
+// (See nmethod::is_at_poll_return())

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

PR Review: https://git.openjdk.org/jdk/pull/18554#pullrequestreview-1978884423

From stefank at openjdk.org  Thu Apr  4 07:57:12 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 4 Apr 2024 07:57:12 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
 [v3]
In-Reply-To: <2sg6I-HBI12rc2LoWYX-A1S5vfMfDyj_5xoykANrZ8g=.6d0e5daa-30e4-45df-990e-c45b63477182@github.com>
References: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
 <2sg6I-HBI12rc2LoWYX-A1S5vfMfDyj_5xoykANrZ8g=.6d0e5daa-30e4-45df-990e-c45b63477182@github.com>
Message-ID: <KGnuaPm9C_Z4xttuvnu0xmyhxK36q4JNO7Z6Ju7BNW4=.29a0b379-3ece-473f-b255-8ec9b22bf680@github.com>

On Thu, 4 Apr 2024 00:05:20 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Revert [JDK-8152664](https://bugs.openjdk.org/browse/JDK-8152664) RFE [changes](https://github.com/openjdk/jdk/commit/b853eb7f5ca24eeeda18acbb14287f706499c365) which was used for AOT [JEP 295](https://openjdk.org/jeps/295) implementation in JDK 9. The code was left in HotSpot assuming it will help in a future. But during work on Leyden we decided to not use it. In Leyden cached compiled code will be restored in CodeCache as normal nmethods: no need to change VM's runtime and GC code to process them.
>> 
>> I may work on optimizing `CodeBlob` and `nmethod` fields layout to reduce header size in separate changes. In these changes I did simple fields reordering to keep small (1 byte) fields together.
>> 
>> I do not see (and not expected) performance difference with these changes.
>> 
>> Tested tier1-5, xcomp, stress. Running performance testing.
>> 
>> I need help with testing on platforms which Oracle does not support.
>
> Vladimir Kozlov 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 five additional commits since the last revision:
> 
>  - Address comments
>  - Merge branch 'master' into 8329332
>  - Removed not_used state of nmethod
>  - remove trailing whitespace
>  - 8329332: Remove CompiledMethod and CodeBlobLayout classes

I took a second pass over the changes. I've given a few suggestions below. None of them should require respinning of tests (except for making sure that this still builds).

src/hotspot/share/code/codeBlob.hpp line 168:

> 166:   bool is_vtable_blob() const                 { return _kind == CodeBlobKind::Blob_Vtable; }
> 167:   bool is_method_handles_adapter_blob() const { return _kind == CodeBlobKind::Blob_MH_Adapter; }
> 168:   bool is_upcall_stub() const                 { return _kind == CodeBlobKind::Blob_Upcall; }

The `Blob_` prefix is now redundant since we always have to prefix with CodeBlobKind::. Just a suggestion if you want to shorten these.

src/hotspot/share/gc/shared/gcBehaviours.hpp line 31:

> 29: #include "oops/oopsHierarchy.hpp"
> 30: 
> 31: // This is the behaviour for checking if a nmethod is unloading

Maybe this should be *an* nmethod?

src/hotspot/share/gc/shenandoah/shenandoahUnload.cpp line 81:

> 79: class ShenandoahIsUnloadingBehaviour : public IsUnloadingBehaviour {
> 80: public:
> 81:   virtual bool has_dead_oop(nmethod* const nm) const {

Is there a reason why this was changed to `nmethod* const nm` instead of `nmethod* nm`? IsUnloadingBehviour::has_dead_oop uses `nmethod* nm`. This question applies to the other changes in this file as well.

src/hotspot/share/gc/x/xUnload.cpp line 78:

> 76: class XIsUnloadingBehaviour : public IsUnloadingBehaviour {
> 77: public:
> 78:   virtual bool has_dead_oop(nmethod* const nm) const {

`nmethod* const nm` => `nmethod* nm`. (ZGC's style is to use const for local variables, but not for variables in the parameter list). The same applies to the rest of the changes to this file.

src/hotspot/share/gc/z/zUnload.cpp line 77:

> 75: class ZIsUnloadingBehaviour : public IsUnloadingBehaviour {
> 76: public:
> 77:   virtual bool has_dead_oop(nmethod* const nm) const {

`nmethod* const nm` => `nmethod* nm`. (ZGC's style is to use const for local variables, but not for variables in the parameter list). The same applies to the rest of the changes to this file.

src/hotspot/share/runtime/javaThread.hpp line 123:

> 121:   DeoptResourceMark*  _deopt_mark;               // Holds special ResourceMark for deoptimization
> 122: 
> 123:   nmethod*       _deopt_nmethod;                 // nmethod that is currently being deoptimized

The alignment is (and was) weird here.

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18554#pullrequestreview-1978954058
PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1551107567
PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1551073461
PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1551077362
PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1551080101
PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1551080280
PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1551100400

From kevinw at openjdk.org  Thu Apr  4 08:05:34 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 4 Apr 2024 08:05:34 GMT
Subject: RFR: 8318026: jcmd should provide access to detailed JVM object
 information [v12]
In-Reply-To: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
Message-ID: <MF9NJ2uqX_Ez6k_m0hMOAtYcarBRMVdH1FepsTXeVgc=.c4dc8914-3460-4892-8e21-bcb720e8401f@github.com>

> Introduce the jcmd "VM.inspect" to implement access to detailed JVM object information.
> 
> Not recommended for live production use.  Requires UnlockDiagnosticVMOptions and not included in jcmd help output, to remind us this is not a general-purpose customer-facing tool.

Kevin Walls 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 26 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into 8318026_jcmd_VMdebug_command
 - One dbg_is_good_oop method
 - Test more pointer types: compiled method and metadata.
 - Argument to be named address.
 - test nit
 - Undo include
 - Change to jcmd VM.inspect
 - Merge remote-tracking branch 'upstream/master' into 8318026_jcmd_VMdebug_command
 - Test update
 - Show description if unknown subcommand.
 - ... and 16 more: https://git.openjdk.org/jdk/compare/ca24041f...e7fc0325

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17655/files
  - new: https://git.openjdk.org/jdk/pull/17655/files/9ed958f6..e7fc0325

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17655&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17655&range=10-11

  Stats: 13189 lines in 329 files changed: 4768 ins; 6005 del; 2416 mod
  Patch: https://git.openjdk.org/jdk/pull/17655.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17655/head:pull/17655

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

From stefank at openjdk.org  Thu Apr  4 09:51:17 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 4 Apr 2024 09:51:17 GMT
Subject: RFR: 8329655: Cleanup KlassObj and klassOop names after the PermGen
 removal
Message-ID: <zrcWyi_nWLR1xaWyzNGAgNwF-5Bq8UKytfN1ygwee04=.45d2ba4e-10cb-4a74-a434-a7df85af0d21@github.com>

We have a few places that uses the terms `KlassObj` and `klassOop` when referring to Klasses. This is old code from before the PermGen removal, when Klasses also were Java objects.

These names tripped me up when I was reading the heap heapInspection.cpp and first though we were mixing the klass *mirror* objects and klass pointers in the hash code calculation:

   // An aligned reference address (typically the least
   // address in the perm gen) used for hashing klass
   // objects.
   HeapWord* _ref;
...
_ref = (HeapWord*) Universe::boolArrayKlassObj();
...
uint KlassInfoTable::hash(const Klass* p) {
  return (uint)(((uintptr_t)p - (uintptr_t)_ref) >> 2);
}


I propose that we rename these functions (and stop casting the Klass* to a (HeapWord*)).

Tested with serviceability/dcmd/gc/ClassHistogramTest.java but will run this through our lower tiers.

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

Commit messages:
 - 8329655:  Cleanup KlassObj and klassOop names after the PermGen removal

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

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

From rkennke at openjdk.org  Thu Apr  4 10:12:10 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 4 Apr 2024 10:12:10 GMT
Subject: RFR: 8329655: Cleanup KlassObj and klassOop names after the
 PermGen removal
In-Reply-To: <zrcWyi_nWLR1xaWyzNGAgNwF-5Bq8UKytfN1ygwee04=.45d2ba4e-10cb-4a74-a434-a7df85af0d21@github.com>
References: <zrcWyi_nWLR1xaWyzNGAgNwF-5Bq8UKytfN1ygwee04=.45d2ba4e-10cb-4a74-a434-a7df85af0d21@github.com>
Message-ID: <3E71V_pKhViBwx-i4vc5T6hk8DZnTOImwI4h5fQzgfE=.8e8e4a69-4f56-463b-b508-bdd5672862a6@github.com>

On Thu, 4 Apr 2024 09:45:58 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> We have a few places that uses the terms `KlassObj` and `klassOop` when referring to Klasses. This is old code from before the PermGen removal, when Klasses also were Java objects.
> 
> These names tripped me up when I was reading the heap heapInspection.cpp and first though we were mixing the klass *mirror* objects and klass pointers in the hash code calculation:
> 
>    // An aligned reference address (typically the least
>    // address in the perm gen) used for hashing klass
>    // objects.
>    HeapWord* _ref;
> ...
> _ref = (HeapWord*) Universe::boolArrayKlassObj();
> ...
> uint KlassInfoTable::hash(const Klass* p) {
>   return (uint)(((uintptr_t)p - (uintptr_t)_ref) >> 2);
> }
> 
> 
> I propose that we rename these functions (and stop casting the Klass* to a (HeapWord*)).
> 
> Tested with serviceability/dcmd/gc/ClassHistogramTest.java but will run this through our lower tiers.

This is a useful change, it has tripped me up a couple of times, too. Change mostly looks good, just a few minor suggestions.

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1202:

> 1200:   ldrw(scan_temp, Address(recv_klass, Klass::vtable_length_offset()));
> 1201: 
> 1202:   // %%% Could store the aligned, prescaled offset in the klassoop.

Unrelated, but what's the point of the %%% in all those comments? Might want to remove that, while you're there.

src/hotspot/share/memory/heapInspection.cpp line 173:

> 171: KlassInfoTable::KlassInfoTable(bool add_all_classes) {
> 172:   _size_of_instances_in_words = 0;
> 173:   _ref = (uintptr_t) Universe::boolArrayKlass();

It seems weird (non-obvious) to cast to uintptr_t here. I see it is only used in KlassInfoTable::hash(), which is weird, too. I am not sure that this even does a useful hashing. Might be worth to get rid of the whole thing and use the [fastHash](https://github.com/rkennke/jdk/blob/JDK-8305896/src/hotspot/share/utilities/fastHash.hpp) stuff that @rose00 proposed for Lilliput. Perhaps in a follow-up. I'd probably either cast to void* or Klass*, or cast to uintptr_t as you did and remove the unnecessary cast in ::hash().

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

Changes requested by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18618#pullrequestreview-1979371014
PR Review Comment: https://git.openjdk.org/jdk/pull/18618#discussion_r1551366745
PR Review Comment: https://git.openjdk.org/jdk/pull/18618#discussion_r1551384583

From sspitsyn at openjdk.org  Thu Apr  4 11:47:59 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 4 Apr 2024 11:47:59 GMT
Subject: RFR: 8329432: PopFrame and ForceEarlyReturn functions should use
 JvmtiHandshake
In-Reply-To: <5tcPHZX0nNTHbQqZfHRl2riTpJglQyGJ2hRJXyIMZPY=.4de7ac6d-dd84-4943-bab1-5dba67bf5cf0@github.com>
References: <5tcPHZX0nNTHbQqZfHRl2riTpJglQyGJ2hRJXyIMZPY=.4de7ac6d-dd84-4943-bab1-5dba67bf5cf0@github.com>
Message-ID: <yUzX-w1UjtXIGPKvnrvkda5qDaMdGkTpJy1RwwEOZ0o=.e04300e1-bd93-40d4-95c0-a6f5acb57bd4@github.com>

On Tue, 2 Apr 2024 00:22:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The internal JVM TI `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor JVM TI functions `PopFrame` and `ForceEarlyReturn` on the base of `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes.
> 
> Testing:
> 
>     Ran mach5 tiers 1-6

Patricio, thank you for review!

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

PR Comment: https://git.openjdk.org/jdk/pull/18570#issuecomment-2036948300

From stefank at openjdk.org  Thu Apr  4 12:11:10 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 4 Apr 2024 12:11:10 GMT
Subject: RFR: 8329655: Cleanup KlassObj and klassOop names after the
 PermGen removal
In-Reply-To: <3E71V_pKhViBwx-i4vc5T6hk8DZnTOImwI4h5fQzgfE=.8e8e4a69-4f56-463b-b508-bdd5672862a6@github.com>
References: <zrcWyi_nWLR1xaWyzNGAgNwF-5Bq8UKytfN1ygwee04=.45d2ba4e-10cb-4a74-a434-a7df85af0d21@github.com>
 <3E71V_pKhViBwx-i4vc5T6hk8DZnTOImwI4h5fQzgfE=.8e8e4a69-4f56-463b-b508-bdd5672862a6@github.com>
Message-ID: <UUaNIcaYef2XY2VBe3jEQWCJhJQtP_mqIyM8zL_whRA=.fed01253-f18c-4b71-a196-ed8c5fa466e6@github.com>

On Thu, 4 Apr 2024 09:55:38 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> We have a few places that uses the terms `KlassObj` and `klassOop` when referring to Klasses. This is old code from before the PermGen removal, when Klasses also were Java objects.
>> 
>> These names tripped me up when I was reading the heap heapInspection.cpp and first though we were mixing the klass *mirror* objects and klass pointers in the hash code calculation:
>> 
>>    // An aligned reference address (typically the least
>>    // address in the perm gen) used for hashing klass
>>    // objects.
>>    HeapWord* _ref;
>> ...
>> _ref = (HeapWord*) Universe::boolArrayKlassObj();
>> ...
>> uint KlassInfoTable::hash(const Klass* p) {
>>   return (uint)(((uintptr_t)p - (uintptr_t)_ref) >> 2);
>> }
>> 
>> 
>> I propose that we rename these functions (and stop casting the Klass* to a (HeapWord*)).
>> 
>> Tested with serviceability/dcmd/gc/ClassHistogramTest.java but will run this through our lower tiers.
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1202:
> 
>> 1200:   ldrw(scan_temp, Address(recv_klass, Klass::vtable_length_offset()));
>> 1201: 
>> 1202:   // %%% Could store the aligned, prescaled offset in the klassoop.
> 
> Unrelated, but what's the point of the %%% in all those comments? Might want to remove that, while you're there.

I think it is an old-style TODO. I'm considering if we shouldn't just remove these comments. What do people think about that?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18618#discussion_r1551548890

From stefank at openjdk.org  Thu Apr  4 12:18:24 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 4 Apr 2024 12:18:24 GMT
Subject: RFR: 8329655: Cleanup KlassObj and klassOop names after the
 PermGen removal [v2]
In-Reply-To: <zrcWyi_nWLR1xaWyzNGAgNwF-5Bq8UKytfN1ygwee04=.45d2ba4e-10cb-4a74-a434-a7df85af0d21@github.com>
References: <zrcWyi_nWLR1xaWyzNGAgNwF-5Bq8UKytfN1ygwee04=.45d2ba4e-10cb-4a74-a434-a7df85af0d21@github.com>
Message-ID: <bPdZLkFPEci1ttjaVvOrEZ1w2vUTJAHhYDOavFjMcyM=.88dd3cd3-5408-476e-bbad-21821932f28d@github.com>

> We have a few places that uses the terms `KlassObj` and `klassOop` when referring to Klasses. This is old code from before the PermGen removal, when Klasses also were Java objects.
> 
> These names tripped me up when I was reading the heap heapInspection.cpp and first though we were mixing the klass *mirror* objects and klass pointers in the hash code calculation:
> 
>    // An aligned reference address (typically the least
>    // address in the perm gen) used for hashing klass
>    // objects.
>    HeapWord* _ref;
> ...
> _ref = (HeapWord*) Universe::boolArrayKlassObj();
> ...
> uint KlassInfoTable::hash(const Klass* p) {
>   return (uint)(((uintptr_t)p - (uintptr_t)_ref) >> 2);
> }
> 
> 
> I propose that we rename these functions (and stop casting the Klass* to a (HeapWord*)).
> 
> Tested with serviceability/dcmd/gc/ClassHistogramTest.java but will run this through our lower tiers.

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Review Roman

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18618/files
  - new: https://git.openjdk.org/jdk/pull/18618/files/02bcbd89..85f6bbe6

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

  Stats: 5 lines in 5 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/18618.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18618/head:pull/18618

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

From rkennke at openjdk.org  Thu Apr  4 12:18:24 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 4 Apr 2024 12:18:24 GMT
Subject: RFR: 8329655: Cleanup KlassObj and klassOop names after the
 PermGen removal [v2]
In-Reply-To: <UUaNIcaYef2XY2VBe3jEQWCJhJQtP_mqIyM8zL_whRA=.fed01253-f18c-4b71-a196-ed8c5fa466e6@github.com>
References: <zrcWyi_nWLR1xaWyzNGAgNwF-5Bq8UKytfN1ygwee04=.45d2ba4e-10cb-4a74-a434-a7df85af0d21@github.com>
 <3E71V_pKhViBwx-i4vc5T6hk8DZnTOImwI4h5fQzgfE=.8e8e4a69-4f56-463b-b508-bdd5672862a6@github.com>
 <UUaNIcaYef2XY2VBe3jEQWCJhJQtP_mqIyM8zL_whRA=.fed01253-f18c-4b71-a196-ed8c5fa466e6@github.com>
Message-ID: <ju2nnqB8YpBe4dgfihkFXba1e2GUBHjy_KpAU87SGHQ=.05809218-0367-4c58-83d3-fb7c5e68586a@github.com>

On Thu, 4 Apr 2024 12:08:23 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1202:
>> 
>>> 1200:   ldrw(scan_temp, Address(recv_klass, Klass::vtable_length_offset()));
>>> 1201: 
>>> 1202:   // %%% Could store the aligned, prescaled offset in the klassoop.
>> 
>> Unrelated, but what's the point of the %%% in all those comments? Might want to remove that, while you're there.
>
> I think it is an old-style TODO. I'm considering if we shouldn't just remove these comments. What do people think about that?

I'm not even sure what they want to say, really. Should be good to remove, and if anybody can make sense of it, record an issue in the bug-tracker?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18618#discussion_r1551557034

From stefank at openjdk.org  Thu Apr  4 12:18:25 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 4 Apr 2024 12:18:25 GMT
Subject: RFR: 8329655: Cleanup KlassObj and klassOop names after the
 PermGen removal [v2]
In-Reply-To: <3E71V_pKhViBwx-i4vc5T6hk8DZnTOImwI4h5fQzgfE=.8e8e4a69-4f56-463b-b508-bdd5672862a6@github.com>
References: <zrcWyi_nWLR1xaWyzNGAgNwF-5Bq8UKytfN1ygwee04=.45d2ba4e-10cb-4a74-a434-a7df85af0d21@github.com>
 <3E71V_pKhViBwx-i4vc5T6hk8DZnTOImwI4h5fQzgfE=.8e8e4a69-4f56-463b-b508-bdd5672862a6@github.com>
Message-ID: <CtR-PQ0nI2k6FAFnVTyQ6DRXrcr1nJUEG3XFwVBAgr0=.618e1849-2a80-427e-b67d-7ab3d35e1251@github.com>

On Thu, 4 Apr 2024 10:07:11 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review Roman
>
> src/hotspot/share/memory/heapInspection.cpp line 173:
> 
>> 171: KlassInfoTable::KlassInfoTable(bool add_all_classes) {
>> 172:   _size_of_instances_in_words = 0;
>> 173:   _ref = (uintptr_t) Universe::boolArrayKlass();
> 
> It seems weird (non-obvious) to cast to uintptr_t here. I see it is only used in KlassInfoTable::hash(), which is weird, too. I am not sure that this even does a useful hashing. Might be worth to get rid of the whole thing and use the [fastHash](https://github.com/rkennke/jdk/blob/JDK-8305896/src/hotspot/share/utilities/fastHash.hpp) stuff that @rose00 proposed for Lilliput. Perhaps in a follow-up. I'd probably either cast to void* or Klass*, or cast to uintptr_t as you did and remove the unnecessary cast in ::hash().

I agree. I'll start by removing the redundant cast in `::hash()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18618#discussion_r1551554904

From stefank at openjdk.org  Thu Apr  4 12:22:12 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 4 Apr 2024 12:22:12 GMT
Subject: RFR: 8329655: Cleanup KlassObj and klassOop names after the
 PermGen removal [v2]
In-Reply-To: <ju2nnqB8YpBe4dgfihkFXba1e2GUBHjy_KpAU87SGHQ=.05809218-0367-4c58-83d3-fb7c5e68586a@github.com>
References: <zrcWyi_nWLR1xaWyzNGAgNwF-5Bq8UKytfN1ygwee04=.45d2ba4e-10cb-4a74-a434-a7df85af0d21@github.com>
 <3E71V_pKhViBwx-i4vc5T6hk8DZnTOImwI4h5fQzgfE=.8e8e4a69-4f56-463b-b508-bdd5672862a6@github.com>
 <UUaNIcaYef2XY2VBe3jEQWCJhJQtP_mqIyM8zL_whRA=.fed01253-f18c-4b71-a196-ed8c5fa466e6@github.com>
 <ju2nnqB8YpBe4dgfihkFXba1e2GUBHjy_KpAU87SGHQ=.05809218-0367-4c58-83d3-fb7c5e68586a@github.com>
Message-ID: <xl1CH7ecKpV2LrOJ5g8DFcIZOoePOva3hP3ZgHumByQ=.43a880aa-4140-489d-bc45-8b28f14369b9@github.com>

On Thu, 4 Apr 2024 12:13:21 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> I think it is an old-style TODO. I'm considering if we shouldn't just remove these comments. What do people think about that?
>
> I'm not even sure what they want to say, really. Should be good to remove, and if anybody can make sense of it, record an issue in the bug-tracker?

OK. I removed the %%%. I'll wait a little bit to see if someone else wants to keep them for some reason, if not, I'll remove them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18618#discussion_r1551568127

From rkennke at openjdk.org  Thu Apr  4 12:42:01 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 4 Apr 2024 12:42:01 GMT
Subject: RFR: 8329655: Cleanup KlassObj and klassOop names after the
 PermGen removal [v2]
In-Reply-To: <bPdZLkFPEci1ttjaVvOrEZ1w2vUTJAHhYDOavFjMcyM=.88dd3cd3-5408-476e-bbad-21821932f28d@github.com>
References: <zrcWyi_nWLR1xaWyzNGAgNwF-5Bq8UKytfN1ygwee04=.45d2ba4e-10cb-4a74-a434-a7df85af0d21@github.com>
 <bPdZLkFPEci1ttjaVvOrEZ1w2vUTJAHhYDOavFjMcyM=.88dd3cd3-5408-476e-bbad-21821932f28d@github.com>
Message-ID: <IOD8pxpJ7qttvlr2NEVD-JB8FeYwkpV4TipOe_rEVG4=.f4b04997-43de-4fc9-b53d-271d7630083c@github.com>

On Thu, 4 Apr 2024 12:18:24 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> We have a few places that uses the terms `KlassObj` and `klassOop` when referring to Klasses. This is old code from before the PermGen removal, when Klasses also were Java objects.
>> 
>> These names tripped me up when I was reading the heap heapInspection.cpp and first though we were mixing the klass *mirror* objects and klass pointers in the hash code calculation:
>> 
>>    // An aligned reference address (typically the least
>>    // address in the perm gen) used for hashing klass
>>    // objects.
>>    HeapWord* _ref;
>> ...
>> _ref = (HeapWord*) Universe::boolArrayKlassObj();
>> ...
>> uint KlassInfoTable::hash(const Klass* p) {
>>   return (uint)(((uintptr_t)p - (uintptr_t)_ref) >> 2);
>> }
>> 
>> 
>> I propose that we rename these functions (and stop casting the Klass* to a (HeapWord*)).
>> 
>> Tested with serviceability/dcmd/gc/ClassHistogramTest.java but will run this through our lower tiers.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Roman

Thanks! Looks good to me, now.

Roman

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

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18618#pullrequestreview-1979767060

From kevinw at openjdk.org  Thu Apr  4 12:46:26 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 4 Apr 2024 12:46:26 GMT
Subject: RFR: 8318026: jcmd should provide access to detailed JVM object
 information [v13]
In-Reply-To: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
Message-ID: <fGGxWRY6cgfm0iY_v4syLiSUh2020_misaHZVV3kPlY=.c2c4be71-5be5-41e4-b93a-7d393816d190@github.com>

> Introduce the jcmd "VM.inspect" to implement access to detailed JVM object information.
> 
> Not recommended for live production use.  Requires UnlockDiagnosticVMOptions and not included in jcmd help output, to remind us this is not a general-purpose customer-facing tool.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  VMInspectTest update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17655/files
  - new: https://git.openjdk.org/jdk/pull/17655/files/e7fc0325..17f22d65

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17655&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17655&range=11-12

  Stats: 82 lines in 1 file changed: 47 ins; 9 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/17655.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17655/head:pull/17655

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

From kevinw at openjdk.org  Thu Apr  4 12:50:03 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 4 Apr 2024 12:50:03 GMT
Subject: RFR: 8318026: jcmd should provide access to detailed JVM object
 information [v11]
In-Reply-To: <3ZAHb7N67_sF8KheEMD2Wb44QX0zgRjkALBx9sk0WhA=.85029ac8-8cda-4f4f-a204-332b4a67d0bf@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
 <dOvDzyHCw8sJixlFGHxhcBhG7ttmqB33pNo5WhIqnKk=.5f505681-d7de-48c4-909a-437852d2cc4d@github.com>
 <3ZAHb7N67_sF8KheEMD2Wb44QX0zgRjkALBx9sk0WhA=.85029ac8-8cda-4f4f-a204-332b4a67d0bf@github.com>
Message-ID: <jvzUIUfpaDO3HPkDSRclMaMLm2A13IvTskUuDv3R0G4=.68713451-93b8-467e-bd45-0d091f21c6bb@github.com>

On Fri, 29 Mar 2024 04:05:53 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test more pointer types: compiled method and metadata.
>
> test/hotspot/jtreg/serviceability/dcmd/vm/VMInspectTest.java line 117:
> 
>> 115:         output = executor.execute("VM.inspect -1");
>> 116:         output.shouldContain("address not safe");
>> 117: 
> 
> Nit: Just a suggestion to make the test more readable. Now when more test cases have been added you may want to refactor it to call a separate method for each sub-test.
> E.g.: `testBaddAddresses()`, `testMisalignedAddress()`, `testCompiledMethodAddress()`, `testMetadataAddress()`, `testClassAddress()`, `testThreadAddress()`, etc.

Thanks, yes have updated the test and split up the tests.

Also added a retry on the Java object inspection part, as I saw a rare failure where the pointer found in Thread.print is no longer correct when we do the inspect.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17655#discussion_r1551614153

From kevinw at openjdk.org  Thu Apr  4 13:00:11 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 4 Apr 2024 13:00:11 GMT
Subject: RFR: 8318026: jcmd should provide access to detailed JVM object
 information [v9]
In-Reply-To: <IML33eLfWNHULkwhOJ65UQ06kjnJb_ZgfaU4-grtejA=.429c10ea-0f17-4723-a405-35584ac94dd1@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
 <rGRHpEl5i0_QUufRwGakZIdspmZ8Qu8Z9VH49-R_5X4=.a391011d-46f7-4e91-913b-075e8c8ecd12@github.com>
 <IML33eLfWNHULkwhOJ65UQ06kjnJb_ZgfaU4-grtejA=.429c10ea-0f17-4723-a405-35584ac94dd1@github.com>
Message-ID: <1csy8earKkqCel2NeF8hgz0P0rkd6smm2E8-h85fXaw=.8e121999-b0b0-4221-8658-8199793abf5d@github.com>

On Wed, 27 Mar 2024 05:26:09 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Undo include
>
> src/hotspot/share/utilities/debug.cpp line 680:
> 
>> 678: 
>> 679: // Additional "good oop" checks, separate method to not disturb existing asserts.
>> 680: extern "C" bool dbg_is_good_oop_detailed(oopDesc* o) {
> 
> What was the motivation for adding this? Is this copied from other HS code? How do we know it's doing a good enough job of verification? What happens if verification is not thorough enough?

On use of dbg_is_good_oop() and do we need our own dbg_is_good_oop_detailed():

The worst case is a crash if the data looks enough like an oop to pass basic checks, but if the klass pointer or a field turns out to be a wild pointer.  So I wanted a stricter and more careful "is good oop" check, e.g. to make it verify the klass pointer is safe, before calling is_klass().  I cannot now see a crash when taking a valid object and examining thousands of what must be wrong pointers in memory after it.

I kept these separate, as had seen an assert when making the existing dbg_is_good_oop more strict.  But that was an error, I had the pointer arithmetic wrong.

This check is called by asserts in two existing places, plus the new diagnosticCommand in this PR.  With this update I'm running all of tier1 OK, which includes ContFramePopTest.java where I could previously trigger an assert.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17655#discussion_r1551632113

From kevinw at openjdk.org  Thu Apr  4 13:09:22 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 4 Apr 2024 13:09:22 GMT
Subject: RFR: 8326666: Remove the Java Management Extension (JMX) Subject
 Delegation feature [v16]
In-Reply-To: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
Message-ID: <963ScTZ1CLP5cWVO79g03y7FLuDbv5xn5-vGcWjTqkA=.2a5006b3-b308-4032-9179-6ebead9833d1@github.com>

> The deprecated Subject Delegation feature in JMX will be removed.
> 
> This was marked in JDK 21 as deprecated for removal (JDK-8298966).

Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:

 - Merge remote-tracking branch 'upstream/master' into 8326666_SubjectDelegation_remove
 - Merge
 - Missing code doc nit.
 - Missing code doc nit.
 - RMIConnectionImpl_Stub also should explicity inherit the unchecked UOE.
 - Clarify JMXConnector equivalence comment.
 - RMIConnectionImpl needs to explicity inherit the unchecked UOE.
 - typo
 - Javadoc update
 - Remove unnecessary constructor in private class
 - ... and 15 more: https://git.openjdk.org/jdk/compare/b9da1401...7fec01c7

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

Changes: https://git.openjdk.org/jdk/pull/18025/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18025&range=15
  Stats: 2026 lines in 35 files changed: 214 ins; 1632 del; 180 mod
  Patch: https://git.openjdk.org/jdk/pull/18025.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18025/head:pull/18025

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

From coleenp at openjdk.org  Thu Apr  4 13:19:14 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 4 Apr 2024 13:19:14 GMT
Subject: RFR: 8313332: Simplify lazy jmethodID cache in InstanceKlass [v4]
In-Reply-To: <Aj-RC_ZNp-5o-36PvFr4wum7e3iyr2hcZtkhI6P7VGY=.fa1fed00-ddac-4dd1-8b21-36c2675598b3@github.com>
References: <OnCG3ISfuvt7bIZaKL5fV8PTaZe8KWs56IWc0XdeoYo=.9d61355a-a4fe-4f6c-9a12-805a9f1febc5@github.com>
 <Aj-RC_ZNp-5o-36PvFr4wum7e3iyr2hcZtkhI6P7VGY=.fa1fed00-ddac-4dd1-8b21-36c2675598b3@github.com>
Message-ID: <l12PATSwSevMdv6qd1hM67UBRZSFI-GvOeOXCAdlupg=.b5757cc5-a8ec-4ae1-bf4d-ba30ad746182@github.com>

On Thu, 4 Apr 2024 00:07:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change simplifies the code that grows the jmethodID cache in InstanceKlass.  Instead of lazily, when there's a rare request for a jmethodID for an obsolete method, the jmethodID cache is grown during the RedefineClasses safepoint.  The InstanceKlass's jmethodID cache is lazily allocated when there's a jmethodID allocated, so not every InstanceKlass has a cache, but the growth now only happens in a safepoint.  This code will become racy with the potential change for deallocating jmethodIDs.
>> 
>> Tested with tier1-4, vmTestbase/nsk/jvmti java/lang/instrument tests (in case they're not in tier1-4).
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Two more.

I've run through tiers 5-7 with the patch now.  Thank you for the reviews Alex, Serguei and Dan.

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

PR Comment: https://git.openjdk.org/jdk/pull/18549#issuecomment-2037185846

From coleenp at openjdk.org  Thu Apr  4 13:19:14 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 4 Apr 2024 13:19:14 GMT
Subject: Integrated: 8313332: Simplify lazy jmethodID cache in InstanceKlass
In-Reply-To: <OnCG3ISfuvt7bIZaKL5fV8PTaZe8KWs56IWc0XdeoYo=.9d61355a-a4fe-4f6c-9a12-805a9f1febc5@github.com>
References: <OnCG3ISfuvt7bIZaKL5fV8PTaZe8KWs56IWc0XdeoYo=.9d61355a-a4fe-4f6c-9a12-805a9f1febc5@github.com>
Message-ID: <yradxL-bnPobx265XBF5I5BZGigWiGImi2zibescir0=.0d46002c-935e-4697-8f43-70de8861c2cc@github.com>

On Fri, 29 Mar 2024 15:25:48 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change simplifies the code that grows the jmethodID cache in InstanceKlass.  Instead of lazily, when there's a rare request for a jmethodID for an obsolete method, the jmethodID cache is grown during the RedefineClasses safepoint.  The InstanceKlass's jmethodID cache is lazily allocated when there's a jmethodID allocated, so not every InstanceKlass has a cache, but the growth now only happens in a safepoint.  This code will become racy with the potential change for deallocating jmethodIDs.
> 
> Tested with tier1-4, vmTestbase/nsk/jvmti java/lang/instrument tests (in case they're not in tier1-4).

This pull request has now been integrated.

Changeset: 21867c92
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/21867c929a2f2c961148f2cd1e79d672ac278d27
Stats:     229 lines in 7 files changed: 44 ins; 151 del; 34 mod

8313332: Simplify lazy jmethodID cache in InstanceKlass

Reviewed-by: amenkov, sspitsyn, dcubed

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

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

From coleenp at openjdk.org  Thu Apr  4 13:34:03 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 4 Apr 2024 13:34:03 GMT
Subject: RFR: 8329655: Cleanup KlassObj and klassOop names after the
 PermGen removal [v2]
In-Reply-To: <bPdZLkFPEci1ttjaVvOrEZ1w2vUTJAHhYDOavFjMcyM=.88dd3cd3-5408-476e-bbad-21821932f28d@github.com>
References: <zrcWyi_nWLR1xaWyzNGAgNwF-5Bq8UKytfN1ygwee04=.45d2ba4e-10cb-4a74-a434-a7df85af0d21@github.com>
 <bPdZLkFPEci1ttjaVvOrEZ1w2vUTJAHhYDOavFjMcyM=.88dd3cd3-5408-476e-bbad-21821932f28d@github.com>
Message-ID: <Ae5Z8ESdK-AZ7ucx6SPzJwf2CmUZ7uH5WcNLFjXsruI=.40e0346f-7041-4375-a0b9-c377c0d29e7e@github.com>

On Thu, 4 Apr 2024 12:18:24 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> We have a few places that uses the terms `KlassObj` and `klassOop` when referring to Klasses. This is old code from before the PermGen removal, when Klasses also were Java objects.
>> 
>> These names tripped me up when I was reading the heap heapInspection.cpp and first though we were mixing the klass *mirror* objects and klass pointers in the hash code calculation:
>> 
>>    // An aligned reference address (typically the least
>>    // address in the perm gen) used for hashing klass
>>    // objects.
>>    HeapWord* _ref;
>> ...
>> _ref = (HeapWord*) Universe::boolArrayKlassObj();
>> ...
>> uint KlassInfoTable::hash(const Klass* p) {
>>   return (uint)(((uintptr_t)p - (uintptr_t)_ref) >> 2);
>> }
>> 
>> 
>> I propose that we rename these functions (and stop casting the Klass* to a (HeapWord*)).
>> 
>> Tested with serviceability/dcmd/gc/ClassHistogramTest.java but will run this through our lower tiers.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Roman

This is good. The Obj was confusing.

src/hotspot/share/memory/heapInspection.hpp line 111:

> 109: 
> 110:   // An aligned reference address (typically the least
> 111:   // address in the perm gen) used for hashing klass

Rats I missed this.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18618#pullrequestreview-1979901207
PR Review Comment: https://git.openjdk.org/jdk/pull/18618#discussion_r1551690175

From coleenp at openjdk.org  Thu Apr  4 13:34:03 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 4 Apr 2024 13:34:03 GMT
Subject: RFR: 8329655: Cleanup KlassObj and klassOop names after the
 PermGen removal [v2]
In-Reply-To: <xl1CH7ecKpV2LrOJ5g8DFcIZOoePOva3hP3ZgHumByQ=.43a880aa-4140-489d-bc45-8b28f14369b9@github.com>
References: <zrcWyi_nWLR1xaWyzNGAgNwF-5Bq8UKytfN1ygwee04=.45d2ba4e-10cb-4a74-a434-a7df85af0d21@github.com>
 <3E71V_pKhViBwx-i4vc5T6hk8DZnTOImwI4h5fQzgfE=.8e8e4a69-4f56-463b-b508-bdd5672862a6@github.com>
 <UUaNIcaYef2XY2VBe3jEQWCJhJQtP_mqIyM8zL_whRA=.fed01253-f18c-4b71-a196-ed8c5fa466e6@github.com>
 <ju2nnqB8YpBe4dgfihkFXba1e2GUBHjy_KpAU87SGHQ=.05809218-0367-4c58-83d3-fb7c5e68586a@github.com>
 <xl1CH7ecKpV2LrOJ5g8DFcIZOoePOva3hP3ZgHumByQ=.43a880aa-4140-489d-bc45-8b28f14369b9@github.com>
Message-ID: <FBtdO-tLCszRbiz1AfuBdmDiT1XY7cxG7bVeL7OoBIg=.5acb09a2-1c69-46a0-97b0-c9886d9d48f6@github.com>

On Thu, 4 Apr 2024 12:19:03 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I'm not even sure what they want to say, really. Should be good to remove, and if anybody can make sense of it, record an issue in the bug-tracker?
>
> OK. I removed the %%%. I'll wait a little bit to see if someone else wants to keep them for some reason, if not, I'll remove them.

I think leaving these comments without the %%% seems fine.  Describing this idea in a CR is a lot more difficult than seeing it in context as commentary, and unless the enhancement has other motivation, it won't be picked up.  Leaving the comment as a clue seems useful.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18618#discussion_r1551686232

From sspitsyn at openjdk.org  Thu Apr  4 15:33:32 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 4 Apr 2024 15:33:32 GMT
Subject: RFR: 8329674: JvmtiEnvThreadState::reset_current_location function
 should use JvmtiHandshake
Message-ID: <uRzHmRzrIpmqOZsolHvTzUW35Gy3m8EQe7rNJjizoOY=.fbac2bc8-acfe-4520-957c-83d7450ff8ce@github.com>

The internal JVM TI JvmtiHandshake and JvmtiUnitedHandshakeClosure classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor the JVM TI internal functions JvmtiEnvThreadState::reset_current_location on the base of JvmtiHandshake and JvmtiUnitedHandshakeClosure classes.

Testing:
 - Ran mach5 tiers 1-6

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

Commit messages:
 - 8329674: JvmtiEnvThreadState::reset_current_location function should use JvmtiHandshake

Changes: https://git.openjdk.org/jdk/pull/18630/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18630&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329674
  Stats: 108 lines in 2 files changed: 35 ins; 67 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/18630.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18630/head:pull/18630

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

From kvn at openjdk.org  Thu Apr  4 15:59:12 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 4 Apr 2024 15:59:12 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
 [v3]
In-Reply-To: <KGnuaPm9C_Z4xttuvnu0xmyhxK36q4JNO7Z6Ju7BNW4=.29a0b379-3ece-473f-b255-8ec9b22bf680@github.com>
References: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
 <2sg6I-HBI12rc2LoWYX-A1S5vfMfDyj_5xoykANrZ8g=.6d0e5daa-30e4-45df-990e-c45b63477182@github.com>
 <KGnuaPm9C_Z4xttuvnu0xmyhxK36q4JNO7Z6Ju7BNW4=.29a0b379-3ece-473f-b255-8ec9b22bf680@github.com>
Message-ID: <Xf-Cp5vIv_E5-s2t0EA0teRwEIZRLQZKAdMhDL3q41I=.640dd40f-a7df-45f1-afc5-183799e60268@github.com>

On Thu, 4 Apr 2024 07:26:21 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Vladimir Kozlov 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 five additional commits since the last revision:
>> 
>>  - Address comments
>>  - Merge branch 'master' into 8329332
>>  - Removed not_used state of nmethod
>>  - remove trailing whitespace
>>  - 8329332: Remove CompiledMethod and CodeBlobLayout classes
>
> src/hotspot/share/gc/shared/gcBehaviours.hpp line 31:
> 
>> 29: #include "oops/oopsHierarchy.hpp"
>> 30: 
>> 31: // This is the behaviour for checking if a nmethod is unloading
> 
> Maybe this should be *an* nmethod?

Quote: "an" goes before words that begin with vowels.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1551989120

From kvn at openjdk.org  Thu Apr  4 16:02:12 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 4 Apr 2024 16:02:12 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
 [v3]
In-Reply-To: <KGnuaPm9C_Z4xttuvnu0xmyhxK36q4JNO7Z6Ju7BNW4=.29a0b379-3ece-473f-b255-8ec9b22bf680@github.com>
References: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
 <2sg6I-HBI12rc2LoWYX-A1S5vfMfDyj_5xoykANrZ8g=.6d0e5daa-30e4-45df-990e-c45b63477182@github.com>
 <KGnuaPm9C_Z4xttuvnu0xmyhxK36q4JNO7Z6Ju7BNW4=.29a0b379-3ece-473f-b255-8ec9b22bf680@github.com>
Message-ID: <SI7n85EeSzaow8NeTQwHFAdV1OS8F7go4oMnO7PgRvM=.ff194cd7-a116-4128-8584-706596151ef0@github.com>

On Thu, 4 Apr 2024 07:31:24 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Vladimir Kozlov 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 five additional commits since the last revision:
>> 
>>  - Address comments
>>  - Merge branch 'master' into 8329332
>>  - Removed not_used state of nmethod
>>  - remove trailing whitespace
>>  - 8329332: Remove CompiledMethod and CodeBlobLayout classes
>
> src/hotspot/share/gc/x/xUnload.cpp line 78:
> 
>> 76: class XIsUnloadingBehaviour : public IsUnloadingBehaviour {
>> 77: public:
>> 78:   virtual bool has_dead_oop(nmethod* const nm) const {
> 
> `nmethod* const nm` => `nmethod* nm`. (ZGC's style is to use const for local variables, but not for variables in the parameter list). The same applies to the rest of the changes to this file.

Okay. I did not know that it is only used for locals. I will update code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1551997411

From stefank at openjdk.org  Thu Apr  4 16:06:14 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 4 Apr 2024 16:06:14 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
 [v3]
In-Reply-To: <Xf-Cp5vIv_E5-s2t0EA0teRwEIZRLQZKAdMhDL3q41I=.640dd40f-a7df-45f1-afc5-183799e60268@github.com>
References: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
 <2sg6I-HBI12rc2LoWYX-A1S5vfMfDyj_5xoykANrZ8g=.6d0e5daa-30e4-45df-990e-c45b63477182@github.com>
 <KGnuaPm9C_Z4xttuvnu0xmyhxK36q4JNO7Z6Ju7BNW4=.29a0b379-3ece-473f-b255-8ec9b22bf680@github.com>
 <Xf-Cp5vIv_E5-s2t0EA0teRwEIZRLQZKAdMhDL3q41I=.640dd40f-a7df-45f1-afc5-183799e60268@github.com>
Message-ID: <GgtzJ6gh2esPs1V2Q5tv4MWk4sSoSGxl7dFNXAk6MdU=.88bb7310-9994-4ddc-96fb-00b2947ddd6c@github.com>

On Thu, 4 Apr 2024 15:56:34 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/gcBehaviours.hpp line 31:
>> 
>>> 29: #include "oops/oopsHierarchy.hpp"
>>> 30: 
>>> 31: // This is the behaviour for checking if a nmethod is unloading
>> 
>> Maybe this should be *an* nmethod?
>
> Quote: "an" goes before words that begin with vowels.

I don't think that holds if the 'n' is pronounced the way nmethod is pronounced.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1552005187

From kvn at openjdk.org  Thu Apr  4 16:09:02 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 4 Apr 2024 16:09:02 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
 [v3]
In-Reply-To: <KGnuaPm9C_Z4xttuvnu0xmyhxK36q4JNO7Z6Ju7BNW4=.29a0b379-3ece-473f-b255-8ec9b22bf680@github.com>
References: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
 <2sg6I-HBI12rc2LoWYX-A1S5vfMfDyj_5xoykANrZ8g=.6d0e5daa-30e4-45df-990e-c45b63477182@github.com>
 <KGnuaPm9C_Z4xttuvnu0xmyhxK36q4JNO7Z6Ju7BNW4=.29a0b379-3ece-473f-b255-8ec9b22bf680@github.com>
Message-ID: <v4khYgI53YgwsNpMUaDWBzR7HAUUBly0tY400kpY1uQ=.32d6b2a2-94a5-4084-9c6c-27276b116e67@github.com>

On Thu, 4 Apr 2024 07:51:47 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Vladimir Kozlov 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 five additional commits since the last revision:
>> 
>>  - Address comments
>>  - Merge branch 'master' into 8329332
>>  - Removed not_used state of nmethod
>>  - remove trailing whitespace
>>  - 8329332: Remove CompiledMethod and CodeBlobLayout classes
>
> src/hotspot/share/code/codeBlob.hpp line 168:
> 
>> 166:   bool is_vtable_blob() const                 { return _kind == CodeBlobKind::Blob_Vtable; }
>> 167:   bool is_method_handles_adapter_blob() const { return _kind == CodeBlobKind::Blob_MH_Adapter; }
>> 168:   bool is_upcall_stub() const                 { return _kind == CodeBlobKind::Blob_Upcall; }
> 
> The `Blob_` prefix is now redundant since we always have to prefix with CodeBlobKind::. Just a suggestion if you want to shorten these.

Good suggestion

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1552009581

From kvn at openjdk.org  Thu Apr  4 16:20:10 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 4 Apr 2024 16:20:10 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
 [v3]
In-Reply-To: <GgtzJ6gh2esPs1V2Q5tv4MWk4sSoSGxl7dFNXAk6MdU=.88bb7310-9994-4ddc-96fb-00b2947ddd6c@github.com>
References: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
 <2sg6I-HBI12rc2LoWYX-A1S5vfMfDyj_5xoykANrZ8g=.6d0e5daa-30e4-45df-990e-c45b63477182@github.com>
 <KGnuaPm9C_Z4xttuvnu0xmyhxK36q4JNO7Z6Ju7BNW4=.29a0b379-3ece-473f-b255-8ec9b22bf680@github.com>
 <Xf-Cp5vIv_E5-s2t0EA0teRwEIZRLQZKAdMhDL3q41I=.640dd40f-a7df-45f1-afc5-183799e60268@github.com>
 <GgtzJ6gh2esPs1V2Q5tv4MWk4sSoSGxl7dFNXAk6MdU=.88bb7310-9994-4ddc-96fb-00b2947ddd6c@github.com>
Message-ID: <9Lk2-DK1nYNPIyXGbhqsr2DfsaR8mQsD9qEevogrW-U=.036ec57b-5fd4-4711-a781-6139f58d419f@github.com>

On Thu, 4 Apr 2024 16:03:12 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Quote: "an" goes before words that begin with vowels.
>
> I don't think that holds if the 'n' is pronounced the way nmethod is pronounced.

`grep` shows that we have both cases but `an nmethod` is used more.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1552024067

From kvn at openjdk.org  Thu Apr  4 16:20:10 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 4 Apr 2024 16:20:10 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
 [v3]
In-Reply-To: <9Lk2-DK1nYNPIyXGbhqsr2DfsaR8mQsD9qEevogrW-U=.036ec57b-5fd4-4711-a781-6139f58d419f@github.com>
References: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
 <2sg6I-HBI12rc2LoWYX-A1S5vfMfDyj_5xoykANrZ8g=.6d0e5daa-30e4-45df-990e-c45b63477182@github.com>
 <KGnuaPm9C_Z4xttuvnu0xmyhxK36q4JNO7Z6Ju7BNW4=.29a0b379-3ece-473f-b255-8ec9b22bf680@github.com>
 <Xf-Cp5vIv_E5-s2t0EA0teRwEIZRLQZKAdMhDL3q41I=.640dd40f-a7df-45f1-afc5-183799e60268@github.com>
 <GgtzJ6gh2esPs1V2Q5tv4MWk4sSoSGxl7dFNXAk6MdU=.88bb7310-9994-4ddc-96fb-00b2947ddd6c@github.com>
 <9Lk2-DK1nYNPIyXGbhqsr2DfsaR8mQsD9qEevogrW-U=.036ec57b-5fd4-4711-a781-6139f58d419f@github.com>
Message-ID: <KOrVRmdv0Wj_fgPPoqmOqI6GCxtZS0QFQe8_pflBlSs=.5f2b2b0b-fae8-4494-bf2b-4595319e1018@github.com>

On Thu, 4 Apr 2024 16:16:41 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> I don't think that holds if the 'n' is pronounced the way nmethod is pronounced.
>
> `grep` shows that we have both cases but `an nmethod` is used more.

I will fix it here as you suggested but I am not touching other places.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18554#discussion_r1552025626

From kevinw at openjdk.org  Thu Apr  4 16:57:22 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 4 Apr 2024 16:57:22 GMT
Subject: Integrated: 8326666: Remove the Java Management Extension (JMX)
 Subject Delegation feature
In-Reply-To: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
Message-ID: <y59ZhqXuUh16j84Kj86wo2xYXv_Pb3ldt6YkgaTk064=.c824b6f0-f0bd-4516-9848-fd198ae77738@github.com>

On Tue, 27 Feb 2024 10:44:20 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> The deprecated Subject Delegation feature in JMX will be removed.
> 
> This was marked in JDK 21 as deprecated for removal (JDK-8298966).

This pull request has now been integrated.

Changeset: 6382a129
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6382a1290fbd7cc8fd097a2972bfcfc06fa4de79
Stats:     2026 lines in 35 files changed: 214 ins; 1632 del; 180 mod

8326666: Remove the Java Management Extension (JMX) Subject Delegation feature

Reviewed-by: mchung, dfuchs

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

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

From kvn at openjdk.org  Thu Apr  4 17:04:30 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 4 Apr 2024 17:04:30 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
 [v4]
In-Reply-To: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
References: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
Message-ID: <2t_Et7WG-YB8Jvu9c3JIByOUM59BUo3DhSORCYFBZbY=.f808def0-15f1-4caa-aa3d-2b9b998b459f@github.com>

> Revert [JDK-8152664](https://bugs.openjdk.org/browse/JDK-8152664) RFE [changes](https://github.com/openjdk/jdk/commit/b853eb7f5ca24eeeda18acbb14287f706499c365) which was used for AOT [JEP 295](https://openjdk.org/jeps/295) implementation in JDK 9. The code was left in HotSpot assuming it will help in a future. But during work on Leyden we decided to not use it. In Leyden cached compiled code will be restored in CodeCache as normal nmethods: no need to change VM's runtime and GC code to process them.
> 
> I may work on optimizing `CodeBlob` and `nmethod` fields layout to reduce header size in separate changes. In these changes I did simple fields reordering to keep small (1 byte) fields together.
> 
> I do not see (and not expected) performance difference with these changes.
> 
> Tested tier1-5, xcomp, stress. Running performance testing.
> 
> I need help with testing on platforms which Oracle does not support.

Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  Address next round of comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18554/files
  - new: https://git.openjdk.org/jdk/pull/18554/files/33768fb2..0c18ff17

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

  Stats: 80 lines in 13 files changed: 0 ins; 0 del; 80 mod
  Patch: https://git.openjdk.org/jdk/pull/18554.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18554/head:pull/18554

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

From kvn at openjdk.org  Thu Apr  4 17:04:31 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 4 Apr 2024 17:04:31 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
 [v3]
In-Reply-To: <KGnuaPm9C_Z4xttuvnu0xmyhxK36q4JNO7Z6Ju7BNW4=.29a0b379-3ece-473f-b255-8ec9b22bf680@github.com>
References: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
 <2sg6I-HBI12rc2LoWYX-A1S5vfMfDyj_5xoykANrZ8g=.6d0e5daa-30e4-45df-990e-c45b63477182@github.com>
 <KGnuaPm9C_Z4xttuvnu0xmyhxK36q4JNO7Z6Ju7BNW4=.29a0b379-3ece-473f-b255-8ec9b22bf680@github.com>
Message-ID: <3IuWX7uxBB3NeXD5nJiBZbh7jr4cxE6pkPr0TXemwag=.b4ad78d3-02eb-435e-a92e-13662779618e@github.com>

On Thu, 4 Apr 2024 07:54:16 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Vladimir Kozlov 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 five additional commits since the last revision:
>> 
>>  - Address comments
>>  - Merge branch 'master' into 8329332
>>  - Removed not_used state of nmethod
>>  - remove trailing whitespace
>>  - 8329332: Remove CompiledMethod and CodeBlobLayout classes
>
> I took a second pass over the changes. I've given a few suggestions below. None of them should require respinning of tests (except for making sure that this still builds).

Thank you, @stefank , for second round of review. I addressed all your comments.
I also removed `virtual` from `virtual method() override;` as you suggested before since I touched these files again.
I will wait result of new GHA and tier1 in mach5 before integration.

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

PR Comment: https://git.openjdk.org/jdk/pull/18554#issuecomment-2037731476

From stefank at openjdk.org  Thu Apr  4 17:34:10 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 4 Apr 2024 17:34:10 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
 [v4]
In-Reply-To: <2t_Et7WG-YB8Jvu9c3JIByOUM59BUo3DhSORCYFBZbY=.f808def0-15f1-4caa-aa3d-2b9b998b459f@github.com>
References: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
 <2t_Et7WG-YB8Jvu9c3JIByOUM59BUo3DhSORCYFBZbY=.f808def0-15f1-4caa-aa3d-2b9b998b459f@github.com>
Message-ID: <wwlsEVmTe9YMETXRsjC0h7zpNtzek1sdUUEJmAJ6ytY=.6ba8b111-8f48-4e4e-9080-983ab12c1a8e@github.com>

On Thu, 4 Apr 2024 17:04:30 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Revert [JDK-8152664](https://bugs.openjdk.org/browse/JDK-8152664) RFE [changes](https://github.com/openjdk/jdk/commit/b853eb7f5ca24eeeda18acbb14287f706499c365) which was used for AOT [JEP 295](https://openjdk.org/jeps/295) implementation in JDK 9. The code was left in HotSpot assuming it will help in a future. But during work on Leyden we decided to not use it. In Leyden cached compiled code will be restored in CodeCache as normal nmethods: no need to change VM's runtime and GC code to process them.
>> 
>> I may work on optimizing `CodeBlob` and `nmethod` fields layout to reduce header size in separate changes. In these changes I did simple fields reordering to keep small (1 byte) fields together.
>> 
>> I do not see (and not expected) performance difference with these changes.
>> 
>> Tested tier1-5, xcomp, stress. Running performance testing.
>> 
>> I need help with testing on platforms which Oracle does not support.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address next round of comments

Looks good.

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18554#pullrequestreview-1980693606

From kvn at openjdk.org  Thu Apr  4 19:26:11 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 4 Apr 2024 19:26:11 GMT
Subject: RFR: 8329332: Remove CompiledMethod and CodeBlobLayout classes
 [v4]
In-Reply-To: <wwlsEVmTe9YMETXRsjC0h7zpNtzek1sdUUEJmAJ6ytY=.6ba8b111-8f48-4e4e-9080-983ab12c1a8e@github.com>
References: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
 <2t_Et7WG-YB8Jvu9c3JIByOUM59BUo3DhSORCYFBZbY=.f808def0-15f1-4caa-aa3d-2b9b998b459f@github.com>
 <wwlsEVmTe9YMETXRsjC0h7zpNtzek1sdUUEJmAJ6ytY=.6ba8b111-8f48-4e4e-9080-983ab12c1a8e@github.com>
Message-ID: <K_-SZ1cVwrt8x-E8kWWOyJTXGWqoaycR5Afl-DJmZJ8=.c787220a-cba8-41c5-ac5c-bfdab54b09a2@github.com>

On Thu, 4 Apr 2024 17:31:53 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address next round of comments
>
> Looks good.

Thank you, @stefank, @iwanowww, @dean-long  and @xmas92 for reviews and @RealFYang and @offamitkumar  for testing.

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

PR Comment: https://git.openjdk.org/jdk/pull/18554#issuecomment-2038043339

From kvn at openjdk.org  Thu Apr  4 19:52:16 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 4 Apr 2024 19:52:16 GMT
Subject: Integrated: 8329332: Remove CompiledMethod and CodeBlobLayout classes
In-Reply-To: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
References: <ImQruaXQMD_OppiLZDYuic6PsiEeXofKOzFAE1XrD0s=.c9d0a2ee-ef41-4e4e-82eb-135405111962@github.com>
Message-ID: <M799FP-Rh1GHLXV8bsMJUqYC-7vjmlLw1HfkX1rkhZM=.02a0218d-952a-4546-9e5d-42aeaea051c6@github.com>

On Fri, 29 Mar 2024 19:35:45 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Revert [JDK-8152664](https://bugs.openjdk.org/browse/JDK-8152664) RFE [changes](https://github.com/openjdk/jdk/commit/b853eb7f5ca24eeeda18acbb14287f706499c365) which was used for AOT [JEP 295](https://openjdk.org/jeps/295) implementation in JDK 9. The code was left in HotSpot assuming it will help in a future. But during work on Leyden we decided to not use it. In Leyden cached compiled code will be restored in CodeCache as normal nmethods: no need to change VM's runtime and GC code to process them.
> 
> I may work on optimizing `CodeBlob` and `nmethod` fields layout to reduce header size in separate changes. In these changes I did simple fields reordering to keep small (1 byte) fields together.
> 
> I do not see (and not expected) performance difference with these changes.
> 
> Tested tier1-5, xcomp, stress. Running performance testing.
> 
> I need help with testing on platforms which Oracle does not support.

This pull request has now been integrated.

Changeset: 83eba863
Author:    Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/83eba863fec5ee7e30c4f9b11122ad1deed3d2ec
Stats:     3941 lines in 119 files changed: 1287 ins; 1753 del; 901 mod

8329332: Remove CompiledMethod and CodeBlobLayout classes

Reviewed-by: vlivanov, stefank

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

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

From sspitsyn at openjdk.org  Thu Apr  4 21:03:04 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 4 Apr 2024 21:03:04 GMT
Subject: RFR: 8318026: jcmd should provide access to detailed JVM object
 information [v13]
In-Reply-To: <fGGxWRY6cgfm0iY_v4syLiSUh2020_misaHZVV3kPlY=.c2c4be71-5be5-41e4-b93a-7d393816d190@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
 <fGGxWRY6cgfm0iY_v4syLiSUh2020_misaHZVV3kPlY=.c2c4be71-5be5-41e4-b93a-7d393816d190@github.com>
Message-ID: <NOY6ovZ0ZBD5x8ib1idqOXBKfNJJ1B-9-xGsQcHyPSw=.96b8f3ed-a835-44d9-ac79-0f491fd49c21@github.com>

On Thu, 4 Apr 2024 12:46:26 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Introduce the jcmd "VM.inspect" to implement access to detailed JVM object information.
>> 
>> Not recommended for live production use.  Requires UnlockDiagnosticVMOptions and not included in jcmd help output, to remind us this is not a general-purpose customer-facing tool.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   VMInspectTest update

The fix looks good to me. I've posted a couple of nits. Do I understand it right that introducing an unlocking option is going to be addressed separately?

test/hotspot/jtreg/serviceability/dcmd/vm/VMInspectTest.java line 189:

> 187:         // so make a few attempts.
> 188:         BigInteger ptr = null;
> 189:         for (int i=0; i < OBJECT_TRIES; i++) {

Nit: Need spaces around `=`.

test/hotspot/jtreg/serviceability/dcmd/vm/VMInspectTest.java line 224:

> 222:                 expected = "is a good oop";
> 223:             }
> 224:         }

Nit: The lines 219-223 can be simplified:
    `expected = isGenZGC ? "is a zaddress" : "is a good oop";

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17655#pullrequestreview-1981143486
PR Review Comment: https://git.openjdk.org/jdk/pull/17655#discussion_r1552427826
PR Review Comment: https://git.openjdk.org/jdk/pull/17655#discussion_r1552434356

From amenkov at openjdk.org  Thu Apr  4 21:34:14 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 4 Apr 2024 21:34:14 GMT
Subject: Integrated: JDK-8322042: HeapDumper should perform merge on the
 current thread instead of VMThread
In-Reply-To: <4--MamzddI0M3jpWu5NG1OvvX2aOo1vTUsH0TNYmty0=.9c4f04fc-2809-427f-9109-6a2f8be3ca5a@github.com>
References: <4--MamzddI0M3jpWu5NG1OvvX2aOo1vTUsH0TNYmty0=.9c4f04fc-2809-427f-9109-6a2f8be3ca5a@github.com>
Message-ID: <mHomRkPsv7_U1kK4vxeUog105ghXVmttrPQ2UTRLSIs=.252a8d0f-3eca-412b-b585-1dc7a255b373@github.com>

On Tue, 2 Apr 2024 00:40:37 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updated HeapDumper to always perform merge on the current thread.
> 
> Testing: tier1-5, all HeapDump-related tests
>   Covered heap dumping scenarios:
>     - `jcmd GC.heap_dump` command;
>     - `HotSpotDiagnosticMXBean.dumpHeap()`;
>     - `HeapDumpBeforeFullGC`, `HeapDumpAfterFullGC` VM options;
>     - `HeapDumpOnOutOfMemoryError` VM option.

This pull request has now been integrated.

Changeset: 12ad09a9
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/12ad09a966030e7ed0900e205df4b412cf0b6a32
Stats:     26 lines in 2 files changed: 0 ins; 22 del; 4 mod

8322042: HeapDumper should perform merge on the current thread instead of VMThread

Reviewed-by: sspitsyn, kevinw

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

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

From stefank at openjdk.org  Fri Apr  5 07:42:06 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 5 Apr 2024 07:42:06 GMT
Subject: RFR: 8329655: Cleanup KlassObj and klassOop names after the
 PermGen removal [v2]
In-Reply-To: <bPdZLkFPEci1ttjaVvOrEZ1w2vUTJAHhYDOavFjMcyM=.88dd3cd3-5408-476e-bbad-21821932f28d@github.com>
References: <zrcWyi_nWLR1xaWyzNGAgNwF-5Bq8UKytfN1ygwee04=.45d2ba4e-10cb-4a74-a434-a7df85af0d21@github.com>
 <bPdZLkFPEci1ttjaVvOrEZ1w2vUTJAHhYDOavFjMcyM=.88dd3cd3-5408-476e-bbad-21821932f28d@github.com>
Message-ID: <64fPE1tLpkAnzHk9HkEF7UoKAW5uejx4cpWsCiCPMDE=.c36728ad-f1d4-4ff3-875f-4abd07a200c0@github.com>

On Thu, 4 Apr 2024 12:18:24 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> We have a few places that uses the terms `KlassObj` and `klassOop` when referring to Klasses. This is old code from before the PermGen removal, when Klasses also were Java objects.
>> 
>> These names tripped me up when I was reading the heap heapInspection.cpp and first though we were mixing the klass *mirror* objects and klass pointers in the hash code calculation:
>> 
>>    // An aligned reference address (typically the least
>>    // address in the perm gen) used for hashing klass
>>    // objects.
>>    HeapWord* _ref;
>> ...
>> _ref = (HeapWord*) Universe::boolArrayKlassObj();
>> ...
>> uint KlassInfoTable::hash(const Klass* p) {
>>   return (uint)(((uintptr_t)p - (uintptr_t)_ref) >> 2);
>> }
>> 
>> 
>> I propose that we rename these functions (and stop casting the Klass* to a (HeapWord*)).
>> 
>> Tested with serviceability/dcmd/gc/ClassHistogramTest.java but will run this through our lower tiers.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Roman

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/18618#issuecomment-2039156773

From stefank at openjdk.org  Fri Apr  5 07:42:07 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 5 Apr 2024 07:42:07 GMT
Subject: Integrated: 8329655: Cleanup KlassObj and klassOop names after the
 PermGen removal
In-Reply-To: <zrcWyi_nWLR1xaWyzNGAgNwF-5Bq8UKytfN1ygwee04=.45d2ba4e-10cb-4a74-a434-a7df85af0d21@github.com>
References: <zrcWyi_nWLR1xaWyzNGAgNwF-5Bq8UKytfN1ygwee04=.45d2ba4e-10cb-4a74-a434-a7df85af0d21@github.com>
Message-ID: <NSB4vEkteuky8VSdsum2DdTw1U45Fbu-KyUhBwWqYJ0=.3ca75359-2ed2-4684-83bf-16eb48a72b16@github.com>

On Thu, 4 Apr 2024 09:45:58 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> We have a few places that uses the terms `KlassObj` and `klassOop` when referring to Klasses. This is old code from before the PermGen removal, when Klasses also were Java objects.
> 
> These names tripped me up when I was reading the heap heapInspection.cpp and first though we were mixing the klass *mirror* objects and klass pointers in the hash code calculation:
> 
>    // An aligned reference address (typically the least
>    // address in the perm gen) used for hashing klass
>    // objects.
>    HeapWord* _ref;
> ...
> _ref = (HeapWord*) Universe::boolArrayKlassObj();
> ...
> uint KlassInfoTable::hash(const Klass* p) {
>   return (uint)(((uintptr_t)p - (uintptr_t)_ref) >> 2);
> }
> 
> 
> I propose that we rename these functions (and stop casting the Klass* to a (HeapWord*)).
> 
> Tested with serviceability/dcmd/gc/ClassHistogramTest.java but will run this through our lower tiers.

This pull request has now been integrated.

Changeset: 71d48bcc
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/71d48bcc3d6313ab4bd031b5e50ae3a16338abc8
Stats:     126 lines in 29 files changed: 0 ins; 2 del; 124 mod

8329655: Cleanup KlassObj and klassOop names after the PermGen removal

Reviewed-by: rkennke, coleenp

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

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

From duke at openjdk.org  Fri Apr  5 09:01:58 2024
From: duke at openjdk.org (Sandra Payne)
Date: Fri, 5 Apr 2024 09:01:58 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v10]
In-Reply-To: <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>
Message-ID: <_XtqPr_EcA256YAbGhyvmuud6R57U-wtioyVSz7IRdM=.20e20363-d998-4deb-99c9-21379a2b19b3@github.com>

On Wed, 27 Mar 2024 13:44:42 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently jcmd command GC.heap_dump only works with an additionally provided file name.
>> Syntax : GC.heap_dump [options] <filename>
>> 
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the <filename> is optional.
>> In case the filename is NOT set, we take the HeapDumpPath (file or directory);
>> 
>> new syntax :
>> GC.heap_dump [options] <filename> .. has precedence over second option
>> GC.heap_dump [options] ?in case -XX: HeapDumpPath=p is set
>> 
>> This would be a simplification e.g. for support cases where a filename or directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the path is intended/recommended for usage also in the jcmd case.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust java.1 man page

I disagree with the premise of this entire request that jcmd GC.heap_dump should follow -XX:HeapDumpPath.
Many customers may see such a change as a regression, as they rely on separation of location for heap dumps generated by the JVM at OOME and heap dumps manually pulled by various other processes attaching to the JVM.

I've been testing this on on JDK 8 and JDK 21 and confirmed in both versions that jcmd requires the filename argument that must be a file, not a directory. Supplying just a directory will fail with either "file exists" or "is a directory", and supplying just a filename without a preceding directory will create the dump in the current working directory (cwd).

Currently, the documentation isn't clear that filename is required.  This should be corrected and also suggest to add %p and %d to the filename, which is useful when you don't want them overwritten with the -overwrite option (JDK 21) or when running heap dumps on multiple processes at once (with a 0 pid  or with main-class specified instead of pid).

Regarding this justification:
> In a cloud environment using containers, the HeapDumpPath is automatically set to a file system service to persist the heapdump. However, if a support engineer or DevOps detects high or increasing memory usage and wants to trigger a heapdump via jcmd, they would need to specify the filename. This requires retrieving the set HeapDumpPath from the app environment and copying it to the jcmd to use the persistent file system. This change can help avoid the need for an additional copy and paste step, which is prone to errors.

It's too weak an argument to justify such a change.  Simple scripts can capture and propagate the HeapDumpPath value, if you really want to go that route.  

However, I recommend using separate directories for manual heap dumps.  Keeping them separate from JVM-initiated heap dumps, either through filename convention or separate directories,  is a best practice.  When you have a severity 1 down situation due to OOME crashes, you don't want to have a bunch of manually pulled heap dumps cluttering up your view of the JVM initiated ones.  You want to be able to get your hands on the exact heap dumps you need very quickly to have them analyzed for root cause.  

For this reason I also disagree with setting a default filename convention equivalent to the default HeapDumpPath filename.  Manual heap dumps require specifying a filename for a reason, and those filenames (and separate directories for those who define them) should be unique based on what triggered the heap dump.  Consider the numerous Support cases of multiple monitoring scripts kicking off jcmd processes to pull heap dumps at various resource usage thresholds, as well as multiple Java agents that may do so, e.g. for various performance reasons.

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2039266399

From mbaesken at openjdk.org  Fri Apr  5 11:04:14 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 5 Apr 2024 11:04:14 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v10]
In-Reply-To: <_XtqPr_EcA256YAbGhyvmuud6R57U-wtioyVSz7IRdM=.20e20363-d998-4deb-99c9-21379a2b19b3@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>
 <_XtqPr_EcA256YAbGhyvmuud6R57U-wtioyVSz7IRdM=.20e20363-d998-4deb-99c9-21379a2b19b3@github.com>
Message-ID: <kb1hnMdAs0-U_AROiVRfLhldptwBzLUrvH3nPLx-0Ro=.1de91c15-6c89-498b-85c5-6bf4eaf4f46a@github.com>

On Fri, 5 Apr 2024 08:57:09 GMT, Sandra Payne <duke at openjdk.org> wrote:

> Many customers may see such a change as a regression, as they rely on separation of location for heap dumps generated by the > JVM at OOME and heap dumps manually pulled by various other processes attaching to the JVM.

With this change it is still possible to have separation (nobody stops users from using jcmd with the  filename option, this is still available).
Or do you think that some tool/script developers would maybe (with this change) in future more use the -XX:HeapDumpPath for **_both_** OOME and jcmd, so that customers would run into this scenario ?

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2039511382

From stefank at openjdk.org  Fri Apr  5 12:37:38 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 5 Apr 2024 12:37:38 GMT
Subject: RFR: 8329629: GC interfaces should work directly against nmethod
 instead of CodeBlob
Message-ID: <FrjeNeatB_30oeaLOmusRqYRCeNXB7oa--CpGdqr1Mc=.b216c2dc-ddac-4c7c-a9f8-b8af2529ff50@github.com>

The GCs scan and handles nmethods and ignores CodeBlobs of other kinds. The I propose that we stop sending in CodeBlobs to the GCs and make sure to only give them nmethods.

I removed `void CodeCache::blobs_do(CodeBlobClosure* f)` since there's no more usage of that function. Is this OK?

I also opted to skipped calling the GC verification code from the iterator code:

Universe::heap()->verify_nmethod((nmethod*)cb);

IMHO, I think it is up to the GCs to decide if they want to perform extra nmethod verification. If someone wants to keep this verification in their favorite GC I can add calls to this function where we used to call CodeCache::blobs_do.

I've only done limited testing and will run extensive testing concurrent with the review.

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

Commit messages:
 - 8329629: GC interfaces should work directly against nmethod instead of CodeBlob

Changes: https://git.openjdk.org/jdk/pull/18653/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18653&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329629
  Stats: 850 lines in 74 files changed: 238 ins; 318 del; 294 mod
  Patch: https://git.openjdk.org/jdk/pull/18653.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18653/head:pull/18653

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

From duke at openjdk.org  Fri Apr  5 12:52:02 2024
From: duke at openjdk.org (Sandra Payne)
Date: Fri, 5 Apr 2024 12:52:02 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v10]
In-Reply-To: <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>
Message-ID: <4c78mA_5urYOxb5YHIlDoQ6lI6t1MTkGBTKSJisO0MA=.3b0b5b07-57ad-4089-abc9-53a867ea3e48@github.com>

On Wed, 27 Mar 2024 13:44:42 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently jcmd command GC.heap_dump only works with an additionally provided file name.
>> Syntax : GC.heap_dump [options] <filename>
>> 
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the <filename> is optional.
>> In case the filename is NOT set, we take the HeapDumpPath (file or directory);
>> 
>> new syntax :
>> GC.heap_dump [options] <filename> .. has precedence over second option
>> GC.heap_dump [options] ?in case -XX: HeapDumpPath=p is set
>> 
>> This would be a simplification e.g. for support cases where a filename or directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the path is intended/recommended for usage also in the jcmd case.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust java.1 man page

Yes, exactly the latter.  With this change, it opens the door for the above scenario to unwittingly occur, either through user error (simple omission of a previously used parameter)  or lack of understanding of the impact not using the parameter will have.

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2039724099

From lujaniuk at openjdk.org  Fri Apr  5 12:55:16 2024
From: lujaniuk at openjdk.org (Ludvig Janiuk)
Date: Fri, 5 Apr 2024 12:55:16 GMT
Subject: RFR: 8329774 Break long lines in jdk/src/jdk.hotspot.agent/doc
 /transported_core.html
Message-ID: <I5Aydb87FJO2kw3amedisLKUmd2K4v22UZAtFn5bhV8=.9dac1556-0acf-4239-817c-05e202d557b6@github.com>

I used "fold -sw 120" and removed trailing whitespaces.

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

Commit messages:
 - 8329774 Break long lines in jdk/src/jdk.hotspot.agent/doc /transported_core.html

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

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

From clanger at openjdk.org  Fri Apr  5 12:57:13 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 5 Apr 2024 12:57:13 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v10]
In-Reply-To: <4c78mA_5urYOxb5YHIlDoQ6lI6t1MTkGBTKSJisO0MA=.3b0b5b07-57ad-4089-abc9-53a867ea3e48@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>
 <4c78mA_5urYOxb5YHIlDoQ6lI6t1MTkGBTKSJisO0MA=.3b0b5b07-57ad-4089-abc9-53a867ea3e48@github.com>
Message-ID: <_xNXWT1GW6jpFNWH4RypV6vFhbY6kbgYGcbrBMmiN00=.72a8b850-805d-4712-80a4-b777a2557c29@github.com>

On Fri, 5 Apr 2024 12:49:53 GMT, Sandra Payne <duke at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adjust java.1 man page
>
> Yes, exactly the latter.  With this change, it opens the door for the above scenario to unwittingly occur, either through user error (simple omission of a previously used parameter)  or lack of understanding of the impact not using the parameter will have.

Hi @spayne8,

thanks for your elaborate answer. Let me comment on your points:
 
> I disagree with the premise of this entire request that jcmd GC.heap_dump should follow -XX:HeapDumpPath. Many customers may see such a change as a regression, as they rely on separation of location for heap dumps generated by the JVM at OOME and heap dumps manually pulled by various other processes attaching to the JVM.

I at least can't see the regression here, because it's still possible to separate the locations of automatic and manual heap dumps by setting a value to the jcmd call.

> Regarding this justification:
> 
> > In a cloud environment using containers, the HeapDumpPath is automatically set to a file system service to persist the heapdump. However, if a support engineer or DevOps detects high or increasing memory usage and wants to trigger a heapdump via jcmd, they would need to specify the filename. This requires retrieving the set HeapDumpPath from the app environment and copying it to the jcmd to use the persistent file system. This change can help avoid the need for an additional copy and paste step, which is prone to errors.
> 
> It's too weak an argument to justify such a change. Simple scripts can capture and propagate the HeapDumpPath value, if you really want to go that route.

Sure but we want to avoid that need and have it more comfortable without having to write scripts.

> However, I recommend using separate directories for manual heap dumps. Keeping them separate from JVM-initiated heap dumps, either through filename convention or separate directories, is a best practice. When you have a severity 1 down situation due to OOME crashes, you don't want to have a bunch of manually pulled heap dumps cluttering up your view of the JVM initiated ones. You want to be able to get your hands on the exact heap dumps you need very quickly to have them analyzed for root cause.

Sure, but the change requested here does not go against that best practice. You still can have different location for manual heap dumps and the file systems should probably cleaned up from old heap dumps anyway.

> For this reason I also disagree with setting a default filename convention equivalent to the default HeapDumpPath filename. Manual heap dumps require specifying a filename for a reason, and those filenames (and separate directories for those who define them) should be unique based on what triggered the heap dump. Consider the numerous Support cases of multiple monitoring scripts kicking off jcmd processes to pull heap dumps at various resource usage thresholds, as well as multiple Java agents that may do so, e.g. for various performance reasons.

Well, I guess, after all it's a bit of a matter of taste. I personally would think having a default for hprof files obtained by jcmd should provide some kind of comfort. Maybe/probably that default should be different from the one for the JVM initiated automatic heapdumps but still it would be helpful if it could be configured, maybe by another XX option.

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2039734474

From amenkov at openjdk.org  Fri Apr  5 22:51:10 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 5 Apr 2024 22:51:10 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v10]
In-Reply-To: <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>
Message-ID: <mSd-82v-Xo9BdY1-ez8pC-6fHAG_Qmy1RQnc1VF0GZA=.28df8a7d-c182-4ebd-85ae-33ab2d56689a@github.com>

On Wed, 27 Mar 2024 13:44:42 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently jcmd command GC.heap_dump only works with an additionally provided file name.
>> Syntax : GC.heap_dump [options] <filename>
>> 
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the <filename> is optional.
>> In case the filename is NOT set, we take the HeapDumpPath (file or directory);
>> 
>> new syntax :
>> GC.heap_dump [options] <filename> .. has precedence over second option
>> GC.heap_dump [options] ?in case -XX: HeapDumpPath=p is set
>> 
>> This would be a simplification e.g. for support cases where a filename or directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the path is intended/recommended for usage also in the jcmd case.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust java.1 man page

I don't have strong opinion if it's good to have default file path for `jcmd GC.heap_dump`, just some thoughts.
We have several ways to heap dump:
1. `-XX:+HeapDumpOnOutOfMemoryError`
2. `-XX:+HeapDumpBeforeFullGC`, `-XX:+HeapDumpAfterFullGC`
   in the case `HeapDumpPath` and `HeapDumpGzipLevel` are used (this is not mentioned in the options' description, need to fix it)
3. `jcmd GC.heap_dump`
4. `jmap -dump`
   it uses "dumpheap" Attach operation, implemented by AttachListener directly
5. `HotSpotDiagnosticMXBean.dumpHeap()`;

Current patch looks inconsistent:
If HeapDumpPath is used as default, HeapDumpGzipLevel should be used as default too (note that default path has different extension depending on HeapDumpGzipLevel);
If (3) has defaults, why (4) and (maybe) (5) don't have the same defaults?

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2040728112

From mbaesken at openjdk.org  Mon Apr  8 06:50:03 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 8 Apr 2024 06:50:03 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v10]
In-Reply-To: <mSd-82v-Xo9BdY1-ez8pC-6fHAG_Qmy1RQnc1VF0GZA=.28df8a7d-c182-4ebd-85ae-33ab2d56689a@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>
 <mSd-82v-Xo9BdY1-ez8pC-6fHAG_Qmy1RQnc1VF0GZA=.28df8a7d-c182-4ebd-85ae-33ab2d56689a@github.com>
Message-ID: <sfFzxeFvWeELNKvIDFpAjmin4aoEYUodDgEy92Blh08=.b0cd7101-3f48-4b50-b3d6-0a6719113107@github.com>

On Fri, 5 Apr 2024 22:47:55 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> I don't have strong opinion if it's good to have default file path for `jcmd GC.heap_dump`, just some thoughts. We have several ways to heap dump:
> 
> 1. `-XX:+HeapDumpOnOutOfMemoryError`
> 2. `-XX:+HeapDumpBeforeFullGC`, `-XX:+HeapDumpAfterFullGC`
>    in the case `HeapDumpPath` and `HeapDumpGzipLevel` are used (this is not mentioned in the options' description, need to fix it)

Was that ever a problem raised by users that the OOME and the GC related heap dumps end up at the same location ?


> 3. `jcmd GC.heap_dump`
> 4. `jmap -dump`
>    it uses "dumpheap" Attach operation, implemented by AttachListener directly
> 5. `HotSpotDiagnosticMXBean.dumpHeap()`;
> 
> Current patch looks inconsistent: If HeapDumpPath is used as default, HeapDumpGzipLevel should be used as default too (note that default path has different extension depending on HeapDumpGzipLevel); If (3) has defaults, why (4) and (maybe) (5) don't have the same defaults?

Yes , probably with 1. + 2,  and now (with the patch) 3. using HeapDumpPath the others should use it most likely too.
(but our users just asked for 3. that's why the patch).
About HeapDumpGzipLevel , I could add this (I think this was already mentioned), but before adding it I wanted to be sure that there the change is supported.

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2041981493

From mbaesken at openjdk.org  Mon Apr  8 13:00:13 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 8 Apr 2024 13:00:13 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v10]
In-Reply-To: <sfFzxeFvWeELNKvIDFpAjmin4aoEYUodDgEy92Blh08=.b0cd7101-3f48-4b50-b3d6-0a6719113107@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>
 <mSd-82v-Xo9BdY1-ez8pC-6fHAG_Qmy1RQnc1VF0GZA=.28df8a7d-c182-4ebd-85ae-33ab2d56689a@github.com>
 <sfFzxeFvWeELNKvIDFpAjmin4aoEYUodDgEy92Blh08=.b0cd7101-3f48-4b50-b3d6-0a6719113107@github.com>
Message-ID: <CD5xLps1XQRUIeG5xzFCR72vwzIEIdCfBi4Q2ZqTU8Y=.65bfce44-51cc-4bea-94d9-769a19bb68a9@github.com>

On Mon, 8 Apr 2024 06:47:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> If (3) has defaults, why (4) and (maybe) (5) don't have the same defaults?

I could open a separate JBS issue (or issues) for scenario 4 and 5 , if this is desired.

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2042690069

From ayang at openjdk.org  Mon Apr  8 13:21:10 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 8 Apr 2024 13:21:10 GMT
Subject: RFR: 8329629: GC interfaces should work directly against nmethod
 instead of CodeBlob
In-Reply-To: <FrjeNeatB_30oeaLOmusRqYRCeNXB7oa--CpGdqr1Mc=.b216c2dc-ddac-4c7c-a9f8-b8af2529ff50@github.com>
References: <FrjeNeatB_30oeaLOmusRqYRCeNXB7oa--CpGdqr1Mc=.b216c2dc-ddac-4c7c-a9f8-b8af2529ff50@github.com>
Message-ID: <SoqzGAfG1GV_P_D1nyQne3ad0iyW-KE2_W7AqHK3J0E=.4e6f96f0-4f5f-4539-a90b-c9d63d7669c5@github.com>

On Fri, 5 Apr 2024 12:32:30 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The GCs scan and handles nmethods and ignores CodeBlobs of other kinds. The I propose that we stop sending in CodeBlobs to the GCs and make sure to only give them nmethods.
> 
> I removed `void CodeCache::blobs_do(CodeBlobClosure* f)` since there's no more usage of that function. Is this OK?
> 
> I also opted to skipped calling the GC verification code from the iterator code:
> 
> Universe::heap()->verify_nmethod((nmethod*)cb);
> 
> IMHO, I think it is up to the GCs to decide if they want to perform extra nmethod verification. If someone wants to keep this verification in their favorite GC I can add calls to this function where we used to call CodeCache::blobs_do.
> 
> I've only done limited testing and will run extensive testing concurrent with the review.

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18653#pullrequestreview-1986431388

From stuefe at openjdk.org  Mon Apr  8 13:23:12 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 8 Apr 2024 13:23:12 GMT
Subject: RFR: 8318026: jcmd should provide access to detailed JVM object
 information [v9]
In-Reply-To: <Od6ytN_fIx6iqNjp1bB5cFUVCm4cXh0MBnmJddZflLk=.00d26c3b-6792-458d-9832-4971b90c3513@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
 <rGRHpEl5i0_QUufRwGakZIdspmZ8Qu8Z9VH49-R_5X4=.a391011d-46f7-4e91-913b-075e8c8ecd12@github.com>
 <FkpkXtC4BSEXGM0uCYWiroHZ4Y4MTdqhjfgb_AbCVOI=.ef819314-1dc5-4460-a807-400887fbeada@github.com>
 <Eh8mqo-MHczioKlpe_o_cvgpWZ9kminPmqNRkKPk0lA=.35465d6a-5668-4dbd-99c9-a43387b4915a@github.com>
 <Od6ytN_fIx6iqNjp1bB5cFUVCm4cXh0MBnmJddZflLk=.00d26c3b-6792-458d-9832-4971b90c3513@github.com>
Message-ID: <AXPdT5eAMU7GU5OKXremisasJBhtzIgnxkbDSifKytA=.32bd8cc0-6b77-40d6-aa1a-ad63e3cd4fec@github.com>

On Thu, 28 Mar 2024 17:15:26 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>>> In my opinion, UnlockDiagnosticVMOptions is not a good enough safeguard since it guards a whole swathe of switches that we may instruct the customer to enable. Once enabled, my experience is that UnlockDiagnosticVMOptions often lingers around. It is not unusual for customer scenarios to have set +UnlockDiagnosticVMOptions because of some years ago support cases.
>> 
>> I think we also need to consider the flip side of this argument. Is this something that some customers might want to always enable, but don't want to always have UnlockDiagnosticVMOptions enabled. A new command line flag would be needed in that case.
>> 
>> Also, isn't UnlockDiagnosticVMOptions meant for enabling the use of diagnostic command line flags? Do we have examples of it enabling a hotspot feature that does not also require setting a diagnostic command line flag?
>
>> I think we also need to consider the flip side of this argument. Is this something that some customers might want to always enable, but don't want to always have UnlockDiagnosticVMOptions enabled. A new command line flag would be needed in that case.
>> 
>> Also, isn't UnlockDiagnosticVMOptions meant for enabling the use of diagnostic command line flags? Do we have examples of it enabling a hotspot feature that does not also require setting a diagnostic command line flag?
> 
> Thanks Chris - that is correct now I check the wording, UnlockDiagnosticVMOptions: "Enable normal processing of flags relating to field diagnostics"
> 
> Yes it makes flags which are DIAGNOSTIC available at the command-line.  We have UnlockExperimentalVMOptions also.
> 
> My original reason for the guard, is that the risk of fooling  the "good oop" check is that we could possibly crash (so that's answering your other question).  Inspecting an arbitrary pointer that looks enough like a Java heap object to fool the test, means it might try and resolve bad addresses for Klass pointer or field data.
> 
> I also have a stress test which examines every address in a Java heap to test for crashes.  That's obviously long-running as it does a jcmd for every iteration.  But I can't currently get a crash, trying G1, ZGC, ZGCGenerational.
> 
> Having a global guard to prevent usage of VM.inspect may be needed less than I thought, but will wait on the other thread before saying that is really the case.  We could have a new -XX flag to guard it (whether specific to this command or a more general UnlockDiagnosticFeatures.  I would definitely stick to this being in all builds, as we frequently "debug" non-debug builds.
> 
> Also, for your comment above about the new version of dbg_is_good_oop: this was added because although there are not many callers of it, I did not want to upset them.  During my earlier testing the detailed version of this method did upset something, although I cannot reproduce that today.  
> 
> I will rerun some tests on these items...

> @kevinjwalls Thanks for clarifying the relevant behaviours and code paths as well as identifying a few places where documentation might help devs avoid tripping over any issues. Much appreciated.

@kevinjwalls I am fine with this as well. Thank you for answering our questions.

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

PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-2042743210

From kevinw at openjdk.org  Mon Apr  8 15:08:13 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 8 Apr 2024 15:08:13 GMT
Subject: RFR: 8318026: jcmd should provide access to detailed JVM object
 information [v9]
In-Reply-To: <AXPdT5eAMU7GU5OKXremisasJBhtzIgnxkbDSifKytA=.32bd8cc0-6b77-40d6-aa1a-ad63e3cd4fec@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
 <rGRHpEl5i0_QUufRwGakZIdspmZ8Qu8Z9VH49-R_5X4=.a391011d-46f7-4e91-913b-075e8c8ecd12@github.com>
 <FkpkXtC4BSEXGM0uCYWiroHZ4Y4MTdqhjfgb_AbCVOI=.ef819314-1dc5-4460-a807-400887fbeada@github.com>
 <Eh8mqo-MHczioKlpe_o_cvgpWZ9kminPmqNRkKPk0lA=.35465d6a-5668-4dbd-99c9-a43387b4915a@github.com>
 <Od6ytN_fIx6iqNjp1bB5cFUVCm4cXh0MBnmJddZflLk=.00d26c3b-6792-458d-9832-4971b90c3513@github.com>
 <AXPdT5eAMU7GU5OKXremisasJBhtzIgnxkbDSifKytA=.32bd8cc0-6b77-40d6-aa1a-ad63e3cd4fec@github.com>
Message-ID: <02edWTcMBzzRLhZPF5CUlH8gmiqRi2ibQmljBIm3G7U=.d99e35b3-e73c-4423-adf7-868954e991f2@github.com>

On Mon, 8 Apr 2024 13:20:03 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Thank you for answering our questions.

No problem, thanks Thomas and Andrew. 8-)

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

PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-2043005639

From kevinw at openjdk.org  Mon Apr  8 15:22:48 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 8 Apr 2024 15:22:48 GMT
Subject: RFR: 8318026: jcmd should provide access to detailed JVM object
 information [v14]
In-Reply-To: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
Message-ID: <vsg2OnFd9IrWxa1P30O92KaR3KicB15wh5d_6hxoDdc=.676ad955-77eb-4b08-970b-0c8347ffe255@github.com>

> Introduce the jcmd "VM.inspect" to implement access to detailed JVM object information.
> 
> Not recommended for live production use.  Requires UnlockDiagnosticVMOptions and not included in jcmd help output, to remind us this is not a general-purpose customer-facing tool.

Kevin Walls 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 29 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into 8318026_jcmd_VMdebug_command
 - Update XX flag requirement
 - VMInspectTest update
 - Merge remote-tracking branch 'upstream/master' into 8318026_jcmd_VMdebug_command
 - One dbg_is_good_oop method
 - Test more pointer types: compiled method and metadata.
 - Argument to be named address.
 - test nit
 - Undo include
 - Change to jcmd VM.inspect
 - ... and 19 more: https://git.openjdk.org/jdk/compare/dfb10c33...510feaa1

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17655/files
  - new: https://git.openjdk.org/jdk/pull/17655/files/17f22d65..510feaa1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17655&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17655&range=12-13

  Stats: 13454 lines in 374 files changed: 5613 ins; 6011 del; 1830 mod
  Patch: https://git.openjdk.org/jdk/pull/17655.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17655/head:pull/17655

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

From kevinw at openjdk.org  Mon Apr  8 15:22:48 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 8 Apr 2024 15:22:48 GMT
Subject: RFR: 8318026: jcmd should provide access to detailed JVM object
 information [v13]
In-Reply-To: <fGGxWRY6cgfm0iY_v4syLiSUh2020_misaHZVV3kPlY=.c2c4be71-5be5-41e4-b93a-7d393816d190@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
 <fGGxWRY6cgfm0iY_v4syLiSUh2020_misaHZVV3kPlY=.c2c4be71-5be5-41e4-b93a-7d393816d190@github.com>
Message-ID: <3WJZ122N0DCzT1Y1tdRHunKwzW142v-yk9edDUJIk1s=.e4c86d6e-5eed-463d-a1ca-3f0ad3227aeb@github.com>

On Thu, 4 Apr 2024 12:46:26 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Introduce the jcmd "VM.inspect" to implement access to detailed JVM object information.
>> 
>> Not recommended for live production use.  Requires UnlockDiagnosticVMOptions and not included in jcmd help output, to remind us this is not a general-purpose customer-facing tool.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   VMInspectTest update

Updating to change the "guard" flag.

I was proposing using a -XX "guard" flag at startup time, to enable jcmd VM.inspect, because it allows inspection of arbitrary pointers given by the the user.  With the improved dbg_is_good_oop I have not managed to cause any crashes, but using the guard flag is a cautious approach.

Will not use UnlockDiagnosticVMOptions as that is intended for command-line option processing.

Therefore a new -XX product flag: -XX:+UnlockDiagnosticVMFeatures which defaults to false and is true in debug builds.

While named similarly to UnlockDiagnosticVMOptions, that option is quite long established and well-documented with many search results, so we should not cause confusion.  The logic is that that option relates to enabling further command-line options, and the new option relates to diagnostic features in the VM at runtime.

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

PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-2043037830

From kevinw at openjdk.org  Mon Apr  8 15:54:30 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 8 Apr 2024 15:54:30 GMT
Subject: RFR: 8318026: jcmd should provide access to detailed JVM object
 information [v15]
In-Reply-To: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
Message-ID: <1H9DSJe1iceX2ADiQC4Gg2kxBN_hAEGMRVl7es5FZrY=.2450f380-6393-4cac-b2a3-49858a212e19@github.com>

> Introduce the jcmd "VM.inspect" to implement access to detailed JVM object information.
> 
> Not recommended for live production use.  Requires UnlockDiagnosticVMOptions and not included in jcmd help output, to remind us this is not a general-purpose customer-facing tool.

Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:

 - Update decode_raw usage to decode_without_asserts, after 8328698
 - nits

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17655/files
  - new: https://git.openjdk.org/jdk/pull/17655/files/510feaa1..7e6c7b97

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17655&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17655&range=13-14

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

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

From sspitsyn at openjdk.org  Mon Apr  8 19:59:11 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 8 Apr 2024 19:59:11 GMT
Subject: RFR: 8318026: jcmd should provide access to detailed JVM object
 information [v15]
In-Reply-To: <1H9DSJe1iceX2ADiQC4Gg2kxBN_hAEGMRVl7es5FZrY=.2450f380-6393-4cac-b2a3-49858a212e19@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
 <1H9DSJe1iceX2ADiQC4Gg2kxBN_hAEGMRVl7es5FZrY=.2450f380-6393-4cac-b2a3-49858a212e19@github.com>
Message-ID: <6DLNxoVyWWllTBSH5qQEwVYqAjzDD0Uom6LTE0K5bFI=.c34ebc7d-56b5-4b90-9629-6b0a4ab5d2eb@github.com>

On Mon, 8 Apr 2024 15:54:30 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Introduce the jcmd "VM.inspect" to implement access to detailed JVM object information.
>> 
>> Not recommended for live production use.  Requires UnlockDiagnosticVMOptions and not included in jcmd help output, to remind us this is not a general-purpose customer-facing tool.
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update decode_raw usage to decode_without_asserts, after 8328698
>  - nits

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17655#pullrequestreview-1987299662

From eosterlund at openjdk.org  Mon Apr  8 20:22:08 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 8 Apr 2024 20:22:08 GMT
Subject: RFR: 8329629: GC interfaces should work directly against nmethod
 instead of CodeBlob
In-Reply-To: <FrjeNeatB_30oeaLOmusRqYRCeNXB7oa--CpGdqr1Mc=.b216c2dc-ddac-4c7c-a9f8-b8af2529ff50@github.com>
References: <FrjeNeatB_30oeaLOmusRqYRCeNXB7oa--CpGdqr1Mc=.b216c2dc-ddac-4c7c-a9f8-b8af2529ff50@github.com>
Message-ID: <cIV1fJ8hpgL1G0DJ_iQuekLhG93cfzUuuzsnjEgp7L8=.989808f7-efac-437c-b4d7-ab42bc37e674@github.com>

On Fri, 5 Apr 2024 12:32:30 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The GCs scan and handles nmethods and ignores CodeBlobs of other kinds. The I propose that we stop sending in CodeBlobs to the GCs and make sure to only give them nmethods.
> 
> I removed `void CodeCache::blobs_do(CodeBlobClosure* f)` since there's no more usage of that function. Is this OK?
> 
> I also opted to skipped calling the GC verification code from the iterator code:
> 
> Universe::heap()->verify_nmethod((nmethod*)cb);
> 
> IMHO, I think it is up to the GCs to decide if they want to perform extra nmethod verification. If someone wants to keep this verification in their favorite GC I can add calls to this function where we used to call CodeCache::blobs_do.
> 
> I've only done limited testing and will run extensive testing concurrent with the review.

Marked as reviewed by eosterlund (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18653#pullrequestreview-1987338271

From lmesnik at openjdk.org  Tue Apr  9 01:12:12 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 9 Apr 2024 01:12:12 GMT
Subject: RFR: 8329491: GetThreadListStackTraces function should use
 JvmtiHandshake [v2]
In-Reply-To: <trwON1_yCYEqtpVxhkGJQJ2rMA7woYCInkqZ1GO1xKc=.3043e002-6d4a-4485-91f7-915515c65df9@github.com>
References: <56L6f8XFyrB_cUSPTLWNIVhO0PU4w3PjRnpA5U7y_aI=.906bf099-af40-4192-a205-f84120e99ec8@github.com>
 <trwON1_yCYEqtpVxhkGJQJ2rMA7woYCInkqZ1GO1xKc=.3043e002-6d4a-4485-91f7-915515c65df9@github.com>
Message-ID: <kUTY9Afydr4NXD8u85_QlFMpBF531r3VvoB8X9fHLF0=.ffc34f04-b143-44ed-8f3d-a9b86d294b94@github.com>

On Tue, 2 Apr 2024 23:52:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The internal JVM TI `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor the JVM TI function `GetThreadListStackTraces` on the base of `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes.
>> 
>> Testing:
>>  - Ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: cleanup - removed temporary logging used for debugging

Changes requested by lmesnik (Reviewer).

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

> 2068: void
> 2069: GetSingleStackTraceClosure::do_thread(Thread *target) {
> 2070:   doit();

I think it makes sense to check that the target is the same as _target_jt. So we don't call it with arbitrary threads.
or require parameter to be null if you want.
Same for do_vthread.

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

PR Review: https://git.openjdk.org/jdk/pull/18574#pullrequestreview-1987905071
PR Review Comment: https://git.openjdk.org/jdk/pull/18574#discussion_r1556678646

From lmesnik at openjdk.org  Tue Apr  9 01:22:09 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 9 Apr 2024 01:22:09 GMT
Subject: RFR: 8329432: PopFrame and ForceEarlyReturn functions should use
 JvmtiHandshake
In-Reply-To: <5tcPHZX0nNTHbQqZfHRl2riTpJglQyGJ2hRJXyIMZPY=.4de7ac6d-dd84-4943-bab1-5dba67bf5cf0@github.com>
References: <5tcPHZX0nNTHbQqZfHRl2riTpJglQyGJ2hRJXyIMZPY=.4de7ac6d-dd84-4943-bab1-5dba67bf5cf0@github.com>
Message-ID: <UAAl9Lv3vsOByC0MfJv3HcOXWusKn4i7ytQLQXaKPKA=.272e7b9c-873f-49ff-bb21-e7e9d964b58a@github.com>

On Tue, 2 Apr 2024 00:22:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The internal JVM TI `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor JVM TI functions `PopFrame` and `ForceEarlyReturn` on the base of `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes.
> 
> Testing:
> 
>     Ran mach5 tiers 1-6

Changes requested by lmesnik (Reviewer).

src/hotspot/share/prims/jvmtiEnvBase.hpp line 503:

> 501:      _value(value),
> 502:      _tos(tos) {}
> 503:   void doit(Thread *target, bool self);

No need to use self, you might use _self from doit().

src/hotspot/share/prims/jvmtiEnvBase.hpp line 508:

> 506:   }
> 507:   void do_vthread(Handle target_h) {
> 508:     assert(_target_jt != nullptr, "sanity check");

Better to test that target_h is same as _target_jt.

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

PR Review: https://git.openjdk.org/jdk/pull/18570#pullrequestreview-1987919902
PR Review Comment: https://git.openjdk.org/jdk/pull/18570#discussion_r1556693843
PR Review Comment: https://git.openjdk.org/jdk/pull/18570#discussion_r1556694346

From syan at openjdk.org  Tue Apr  9 01:54:18 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 9 Apr 2024 01:54:18 GMT
Subject: RFR: 8323640: [TESTBUG]testMemoryFailCount in
 jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
 OOM killed [v3]
In-Reply-To: <0IxU-_67a-IptNmtVq0L0a331lH6MGKDEAkQaCnE3Us=.2bbb3993-b6f9-4eff-a59e-0d9cf48cc431@github.com>
References: <sH7GERe4nUM_7p7cJZwMTyEwUrt-6rojzyjclQ4SQTo=.d98d228c-399a-443a-97c5-e8e65c689ade@github.com>
 <0IxU-_67a-IptNmtVq0L0a331lH6MGKDEAkQaCnE3Us=.2bbb3993-b6f9-4eff-a59e-0d9cf48cc431@github.com>
Message-ID: <x47N3T-ft00FFdjWzImGgebY2W5F5lnj6HpjDWzEaoc=.0090ce6c-615d-4181-9c8d-4f8e82df6ce3@github.com>

On Tue, 23 Jan 2024 13:04:43 GMT, SendaoYan <syan at openjdk.org> wrote:

>> 8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8323640: [TESTBUG]testMemoryFailCount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because OOM killed
>   
>   Signed-off-by: sendaoYan <yansendao.ysd at alibaba-inc.com>

> /sponsor

@jerboaa Thanks for the review and the sponsor.

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

PR Comment: https://git.openjdk.org/jdk/pull/17514#issuecomment-2044000397

From dholmes at openjdk.org  Tue Apr  9 06:03:11 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 9 Apr 2024 06:03:11 GMT
Subject: RFR: 8318026: jcmd should provide access to detailed JVM object
 information [v15]
In-Reply-To: <1H9DSJe1iceX2ADiQC4Gg2kxBN_hAEGMRVl7es5FZrY=.2450f380-6393-4cac-b2a3-49858a212e19@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
 <1H9DSJe1iceX2ADiQC4Gg2kxBN_hAEGMRVl7es5FZrY=.2450f380-6393-4cac-b2a3-49858a212e19@github.com>
Message-ID: <m_1lfYzJQs3Qkl2Xu08-sVgFyuB8I3kiBVVSJVGKZg0=.0c97efc9-34fe-46bc-8f27-ac441fd082ed@github.com>

On Mon, 8 Apr 2024 15:54:30 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Introduce the jcmd "VM.inspect" to implement access to detailed JVM object information.
>> 
>> Not recommended for live production use.  Requires UnlockDiagnosticVMOptions and not included in jcmd help output, to remind us this is not a general-purpose customer-facing tool.
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update decode_raw usage to decode_without_asserts, after 8328698
>  - nits

The new flag needs to be covered by the CSR request.

I'm not too sure about it as it sounds far too general. I would have expected something that was obviously connected to jcmd and/or the specific jcmd under discussion. I can't really imagine that we would have a number of such features that we would want to turn on or off together.

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

PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-2044205481

From stefank at openjdk.org  Tue Apr  9 07:28:40 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 9 Apr 2024 07:28:40 GMT
Subject: RFR: 8329629: GC interfaces should work directly against nmethod
 instead of CodeBlob [v2]
In-Reply-To: <FrjeNeatB_30oeaLOmusRqYRCeNXB7oa--CpGdqr1Mc=.b216c2dc-ddac-4c7c-a9f8-b8af2529ff50@github.com>
References: <FrjeNeatB_30oeaLOmusRqYRCeNXB7oa--CpGdqr1Mc=.b216c2dc-ddac-4c7c-a9f8-b8af2529ff50@github.com>
Message-ID: <P3FyeF5oVtIJkCWYpKhocnA5gzwnY2wBwChflw2RoeU=.e77e54de-edf6-4c07-b628-1dd3a0eaa4bb@github.com>

> The GCs scan and handles nmethods and ignores CodeBlobs of other kinds. The I propose that we stop sending in CodeBlobs to the GCs and make sure to only give them nmethods.
> 
> I removed `void CodeCache::blobs_do(CodeBlobClosure* f)` since there's no more usage of that function. Is this OK?
> 
> I also opted to skipped calling the GC verification code from the iterator code:
> 
> Universe::heap()->verify_nmethod((nmethod*)cb);
> 
> IMHO, I think it is up to the GCs to decide if they want to perform extra nmethod verification. If someone wants to keep this verification in their favorite GC I can add calls to this function where we used to call CodeCache::blobs_do.
> 
> I've only done limited testing and will run extensive testing concurrent with the review.

Stefan Karlsson 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 remote-tracking branch 'upstream/master' into 8329629_do_code_blob
 - 8329629: GC interfaces should work directly against nmethod instead of CodeBlob

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18653/files
  - new: https://git.openjdk.org/jdk/pull/18653/files/e10683e2..1c2bdaea

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

  Stats: 5545 lines in 115 files changed: 3743 ins; 1387 del; 415 mod
  Patch: https://git.openjdk.org/jdk/pull/18653.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18653/head:pull/18653

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

From stefank at openjdk.org  Tue Apr  9 07:28:40 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 9 Apr 2024 07:28:40 GMT
Subject: RFR: 8329629: GC interfaces should work directly against nmethod
 instead of CodeBlob
In-Reply-To: <FrjeNeatB_30oeaLOmusRqYRCeNXB7oa--CpGdqr1Mc=.b216c2dc-ddac-4c7c-a9f8-b8af2529ff50@github.com>
References: <FrjeNeatB_30oeaLOmusRqYRCeNXB7oa--CpGdqr1Mc=.b216c2dc-ddac-4c7c-a9f8-b8af2529ff50@github.com>
Message-ID: <YDqSWAJuSm7Gy3zkm_sKrsicCTHd8eoASeQZYtwNgYY=.42e735cf-81b3-4165-b064-7416daba1310@github.com>

On Fri, 5 Apr 2024 12:32:30 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The GCs scan and handles nmethods and ignores CodeBlobs of other kinds. The I propose that we stop sending in CodeBlobs to the GCs and make sure to only give them nmethods.
> 
> I removed `void CodeCache::blobs_do(CodeBlobClosure* f)` since there's no more usage of that function. Is this OK?
> 
> I also opted to skipped calling the GC verification code from the iterator code:
> 
> Universe::heap()->verify_nmethod((nmethod*)cb);
> 
> IMHO, I think it is up to the GCs to decide if they want to perform extra nmethod verification. If someone wants to keep this verification in their favorite GC I can add calls to this function where we used to call CodeCache::blobs_do.
> 
> I've only done limited testing and will run extensive testing concurrent with the review.

Thanks for the reviews! I'll let GHA complete before integrating.

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

PR Comment: https://git.openjdk.org/jdk/pull/18653#issuecomment-2044313453

From kevinw at openjdk.org  Tue Apr  9 11:24:29 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 9 Apr 2024 11:24:29 GMT
Subject: RFR: 8188784:
 javax/management/notification/BroadcasterSupportDeadlockTest.java - TEST
 FAILED: deadlock
Message-ID: <SjE2qD8hJjpNsEKrYBEzJm--eJ3p21uZS7M6ydlB8ow=.1bd99464-5794-4cb6-80b6-3245e8b71c39@github.com>

This test incorrectly fails, although rarely, thinking its "thread 2" has deadlocked.
A change of sleep will likely fix this, but there are other issues, so cleaning up the test a little.

Remove the probe for the ManagementFactory class, to check we are on jdk5 or later. 8-)

When sleeping, sleep 100, not 1ms, we don't need to spin fast and actually race with the other thread.

We have a 1000 iteration loop, but don't seem to use it.  We only check once then either return (pass), fail, or break (which is also fail).  Use the loop to check for the status change, which is likely what was intended.

Show the stackframes on all failures.

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

Commit messages:
 - 8188784: javax/management/notification/BroadcasterSupportDeadlockTest.java - TEST FAILED: deadlock

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

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

From kevinw at openjdk.org  Tue Apr  9 12:14:00 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 9 Apr 2024 12:14:00 GMT
Subject: RFR: 8318026: jcmd should provide access to detailed JVM object
 information [v15]
In-Reply-To: <m_1lfYzJQs3Qkl2Xu08-sVgFyuB8I3kiBVVSJVGKZg0=.0c97efc9-34fe-46bc-8f27-ac441fd082ed@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
 <1H9DSJe1iceX2ADiQC4Gg2kxBN_hAEGMRVl7es5FZrY=.2450f380-6393-4cac-b2a3-49858a212e19@github.com>
 <m_1lfYzJQs3Qkl2Xu08-sVgFyuB8I3kiBVVSJVGKZg0=.0c97efc9-34fe-46bc-8f27-ac441fd082ed@github.com>
Message-ID: <2JE8Y1uzmUBOxQ-AkwV4Hhy-Hdl7XhDoAgPoAIgX5is=.03c74593-cd32-4b1f-82cc-e8f0923dd5e7@github.com>

On Tue, 9 Apr 2024 06:00:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

> sounds far too general. I would have expected something that was obviously connected to jcmd and/or the specific jcmd under discussion.

I don't expect so many more of these, but EnableVMInspectDCmd looked too specific, I didn't want to pursue a 1:1 mapping of a diagnostic command to feature, so looked for something more general.

To HotSpot it's a Diagnostic Command, to users it's a jcmd, so maybe don't want to specifically say either in the flag.

But EnableVMInspect is not right (there are many ways we inspect the VM!), and EnableVMInspectFeatures or UnlockVMInspectionFeatures again might be too generic.


Next suggestion:

EnableVMInspectCommand

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

PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-2045006108

From stefank at openjdk.org  Tue Apr  9 12:31:21 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 9 Apr 2024 12:31:21 GMT
Subject: Integrated: 8329629: GC interfaces should work directly against
 nmethod instead of CodeBlob
In-Reply-To: <FrjeNeatB_30oeaLOmusRqYRCeNXB7oa--CpGdqr1Mc=.b216c2dc-ddac-4c7c-a9f8-b8af2529ff50@github.com>
References: <FrjeNeatB_30oeaLOmusRqYRCeNXB7oa--CpGdqr1Mc=.b216c2dc-ddac-4c7c-a9f8-b8af2529ff50@github.com>
Message-ID: <kFpO1Tq7tHMOBKYEjCwO6Yjbov4E7mWqChBkkico45w=.74d68d0c-1daf-4483-9290-6630560225c0@github.com>

On Fri, 5 Apr 2024 12:32:30 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The GCs scan and handles nmethods and ignores CodeBlobs of other kinds. The I propose that we stop sending in CodeBlobs to the GCs and make sure to only give them nmethods.
> 
> I removed `void CodeCache::blobs_do(CodeBlobClosure* f)` since there's no more usage of that function. Is this OK?
> 
> I also opted to skipped calling the GC verification code from the iterator code:
> 
> Universe::heap()->verify_nmethod((nmethod*)cb);
> 
> IMHO, I think it is up to the GCs to decide if they want to perform extra nmethod verification. If someone wants to keep this verification in their favorite GC I can add calls to this function where we used to call CodeCache::blobs_do.
> 
> I've only done limited testing and will run extensive testing concurrent with the review.

This pull request has now been integrated.

Changeset: 87131fb2
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/87131fb2f77188a483fd0852da5f9228aafd5336
Stats:     850 lines in 74 files changed: 238 ins; 318 del; 294 mod

8329629: GC interfaces should work directly against nmethod instead of CodeBlob

Reviewed-by: ayang, eosterlund

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

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

From lmesnik at openjdk.org  Tue Apr  9 19:51:00 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 9 Apr 2024 19:51:00 GMT
Subject: RFR: 8329674: JvmtiEnvThreadState::reset_current_location function
 should use JvmtiHandshake
In-Reply-To: <uRzHmRzrIpmqOZsolHvTzUW35Gy3m8EQe7rNJjizoOY=.fbac2bc8-acfe-4520-957c-83d7450ff8ce@github.com>
References: <uRzHmRzrIpmqOZsolHvTzUW35Gy3m8EQe7rNJjizoOY=.fbac2bc8-acfe-4520-957c-83d7450ff8ce@github.com>
Message-ID: <aes_O1__rInSfsdFippk_fxOcEcTUnIek4FreqfSXTo=.d7e7241e-4cb3-4f63-8e9d-cda15efb3931@github.com>

On Thu, 4 Apr 2024 15:28:41 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The internal JVM TI JvmtiHandshake and JvmtiUnitedHandshakeClosure classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor the JVM TI internal functions JvmtiEnvThreadState::reset_current_location on the base of JvmtiHandshake and JvmtiUnitedHandshakeClosure classes.
> 
> Testing:
>  - Ran mach5 tiers 1-6

The fix looks good.
It would be better to either rename doit methods to something more specific or even to move code into do_thread and do_vthread. 
And make do_vthread like

void do_vthread(Handle target_h) {
    if (_target_jt != nullptr) {
      do_thread(_target_jt);
    } else {
     <  code for unmounted >
    }
  }

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

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18630#pullrequestreview-1990029643

From cjplummer at openjdk.org  Tue Apr  9 21:29:08 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 9 Apr 2024 21:29:08 GMT
Subject: RFR: 8329774 Break long lines in jdk/src/jdk.hotspot.agent/doc
 /transported_core.html
In-Reply-To: <I5Aydb87FJO2kw3amedisLKUmd2K4v22UZAtFn5bhV8=.9dac1556-0acf-4239-817c-05e202d557b6@github.com>
References: <I5Aydb87FJO2kw3amedisLKUmd2K4v22UZAtFn5bhV8=.9dac1556-0acf-4239-817c-05e202d557b6@github.com>
Message-ID: <vI3znqiCl_gCVbcx2537lQTUXdMsArnkfYwGHcV9cFw=.3b3dd0da-37d6-40ed-889e-0f75a0a70a73@github.com>

On Fri, 5 Apr 2024 12:50:04 GMT, Ludvig Janiuk <lujaniuk at openjdk.org> wrote:

> I used "fold -sw 120" and removed trailing whitespaces.

I think using 100 would be more consistent with the rest of the file, although you may need to undo some long "code" lines after the initial reformat.

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

PR Comment: https://git.openjdk.org/jdk/pull/18654#issuecomment-2046078411

From manc at openjdk.org  Tue Apr  9 22:21:23 2024
From: manc at openjdk.org (Man Cao)
Date: Tue, 9 Apr 2024 22:21:23 GMT
Subject: RFR: 8327645: Serial heap dump should not consume double amount of
 disk space [v3]
In-Reply-To: <w0s7BM73-cxeWAZz9s42cfLgJPMafLsWfQhnlZ4pakk=.bafbcb0f-94c9-41bd-9226-71979a76800a@github.com>
References: <w0s7BM73-cxeWAZz9s42cfLgJPMafLsWfQhnlZ4pakk=.bafbcb0f-94c9-41bd-9226-71979a76800a@github.com>
Message-ID: <rdnsXmnqIuKrlJJTkC3iqNfSCnGmS7vEEUDTkR7vVLA=.0bb2e48a-c170-4293-bd04-d667eaf55c5d@github.com>

> Hi all,
> 
> Could anyone review this fix to make serial heap dump only write to a single file?
> We highly appreciate the work in https://bugs.openjdk.org/browse/JDK-8306441. However, many of our customers still need to use serial heap dump, as they have limited disk space and need to dump to a network socket.
> 
> Tested:
> Stress tested with a fastdebug build with tests in `hotspot/jtreg/serviceability/dcmd/gc/HeapDump*`.
> 
> -Man

Man Cao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge branch 'master' into JDK-8327645-serialdump
 - Add a variant to run serial heap dump for VThreadInHeapDump
 - Fix failure under -XX:+UseSerialGC
 - 8327645: Serial heap dump should not consume double amount of disk space

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

Changes: https://git.openjdk.org/jdk/pull/18160/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18160&range=02
  Stats: 55 lines in 2 files changed: 24 ins; 0 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/18160.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18160/head:pull/18160

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

From sspitsyn at openjdk.org  Tue Apr  9 22:26:08 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 9 Apr 2024 22:26:08 GMT
Subject: RFR: 8329432: PopFrame and ForceEarlyReturn functions should use
 JvmtiHandshake
In-Reply-To: <UAAl9Lv3vsOByC0MfJv3HcOXWusKn4i7ytQLQXaKPKA=.272e7b9c-873f-49ff-bb21-e7e9d964b58a@github.com>
References: <5tcPHZX0nNTHbQqZfHRl2riTpJglQyGJ2hRJXyIMZPY=.4de7ac6d-dd84-4943-bab1-5dba67bf5cf0@github.com>
 <UAAl9Lv3vsOByC0MfJv3HcOXWusKn4i7ytQLQXaKPKA=.272e7b9c-873f-49ff-bb21-e7e9d964b58a@github.com>
Message-ID: <H-zZWqYbTuioFUKsx7DzqbIgijMV9IdZ_pONfrshCJg=.2b67bffc-ed68-41c6-ba84-f89aff0c9f33@github.com>

On Tue, 9 Apr 2024 01:18:35 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The internal JVM TI `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor JVM TI functions `PopFrame` and `ForceEarlyReturn` on the base of `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes.
>> 
>> Testing:
>> 
>>     Ran mach5 tiers 1-6
>
> src/hotspot/share/prims/jvmtiEnvBase.hpp line 503:
> 
>> 501:      _value(value),
>> 502:      _tos(tos) {}
>> 503:   void doit(Thread *target, bool self);
> 
> No need to use self, you might use _self from doit().

Good suggestion, thanks.
The UpdateForPopTopFrameClosure::doit has the same issue. Fixed both now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18570#discussion_r1558367607

From sspitsyn at openjdk.org  Tue Apr  9 22:31:10 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 9 Apr 2024 22:31:10 GMT
Subject: RFR: 8329432: PopFrame and ForceEarlyReturn functions should use
 JvmtiHandshake
In-Reply-To: <UAAl9Lv3vsOByC0MfJv3HcOXWusKn4i7ytQLQXaKPKA=.272e7b9c-873f-49ff-bb21-e7e9d964b58a@github.com>
References: <5tcPHZX0nNTHbQqZfHRl2riTpJglQyGJ2hRJXyIMZPY=.4de7ac6d-dd84-4943-bab1-5dba67bf5cf0@github.com>
 <UAAl9Lv3vsOByC0MfJv3HcOXWusKn4i7ytQLQXaKPKA=.272e7b9c-873f-49ff-bb21-e7e9d964b58a@github.com>
Message-ID: <lJKf1f0QIIekD_1d7ilGVXrLTwZgpFccpiHzxTokfLY=.894b88c9-95fc-42a1-9291-3bb3b0836c1c@github.com>

On Tue, 9 Apr 2024 01:19:18 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The internal JVM TI `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor JVM TI functions `PopFrame` and `ForceEarlyReturn` on the base of `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes.
>> 
>> Testing:
>> 
>>     Ran mach5 tiers 1-6
>
> src/hotspot/share/prims/jvmtiEnvBase.hpp line 508:
> 
>> 506:   }
>> 507:   void do_vthread(Handle target_h) {
>> 508:     assert(_target_jt != nullptr, "sanity check");
> 
> Better to test that target_h is same as _target_jt.

Thanks.
The `_target_jt` is a `JavaThread*` while the `target_h` is a handle of thread oop.
Added the following assert: `assert(_target_jt->vthread() == target_h(), "sanity check");`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18570#discussion_r1558372501

From amenkov at openjdk.org  Wed Apr 10 00:32:19 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 10 Apr 2024 00:32:19 GMT
Subject: RFR: JDK-8240343: JDI stopListening/stoplis001
 "FAILED: listening is successfully stopped without starting listening"
Message-ID: <iGvL2MQ9wvrjf5QKf9zd0LEF-KAnUZrUPXM0k3bQluE=.6cd6c780-75f9-412a-aa39-10e1b00a90a3@github.com>

The test starts listening on dynamic port and calls stopListening with incorrect (cArgs1) and correct (cArgs2) argument maps.
Incorrect map is created by finding "free" port (`(new ServerSocket(0)).getLocalPort()`)
The test fails if the same port is selected later when the listening starts.
To avoid this free port should be picked after listening on dynamic port started.

Additionally removed unnecessary `exclusiveAccess.dirs=.` test property and incorrect comment in the description.
The test uses `SocketListen` connectors, the coment is about `SharedMemoryListen` connector.

Testing: run the test on all Oracle-supported platforms 100 times

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

Commit messages:
 - fix

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

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

From dholmes at openjdk.org  Wed Apr 10 02:29:10 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 10 Apr 2024 02:29:10 GMT
Subject: RFR: 8318026: jcmd should provide access to detailed JVM object
 information [v15]
In-Reply-To: <2JE8Y1uzmUBOxQ-AkwV4Hhy-Hdl7XhDoAgPoAIgX5is=.03c74593-cd32-4b1f-82cc-e8f0923dd5e7@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
 <1H9DSJe1iceX2ADiQC4Gg2kxBN_hAEGMRVl7es5FZrY=.2450f380-6393-4cac-b2a3-49858a212e19@github.com>
 <m_1lfYzJQs3Qkl2Xu08-sVgFyuB8I3kiBVVSJVGKZg0=.0c97efc9-34fe-46bc-8f27-ac441fd082ed@github.com>
 <2JE8Y1uzmUBOxQ-AkwV4Hhy-Hdl7XhDoAgPoAIgX5is=.03c74593-cd32-4b1f-82cc-e8f0923dd5e7@github.com>
Message-ID: <6yS049uFhhqyJzHRh-la_HWhp-yTKU3fmI9-3YMx96A=.3a14245c-a821-4627-ab3c-90c27cd63c7c@github.com>

On Tue, 9 Apr 2024 12:10:57 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> EnableVMInspectCommand

I can live with that.

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

PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-2046351694

From sspitsyn at openjdk.org  Wed Apr 10 02:34:37 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 10 Apr 2024 02:34:37 GMT
Subject: RFR: 8329432: PopFrame and ForceEarlyReturn functions should use
 JvmtiHandshake [v2]
In-Reply-To: <5tcPHZX0nNTHbQqZfHRl2riTpJglQyGJ2hRJXyIMZPY=.4de7ac6d-dd84-4943-bab1-5dba67bf5cf0@github.com>
References: <5tcPHZX0nNTHbQqZfHRl2riTpJglQyGJ2hRJXyIMZPY=.4de7ac6d-dd84-4943-bab1-5dba67bf5cf0@github.com>
Message-ID: <4pX8bccxXZCq1XNpmOpjY4fRQ6G9TZiv_BYTlw6hIxU=.9c9fda52-ce07-40d3-9528-37c140986fe1@github.com>

> The internal JVM TI `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor JVM TI functions `PopFrame` and `ForceEarlyReturn` on the base of `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes.
> 
> Testing:
> 
>     Ran mach5 tiers 1-6

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

  review: remove self from args; add asserts

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18570/files
  - new: https://git.openjdk.org/jdk/pull/18570/files/9ca1ea20..d46813da

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

  Stats: 10 lines in 2 files changed: 2 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/18570.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18570/head:pull/18570

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

From sspitsyn at openjdk.org  Wed Apr 10 02:48:09 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 10 Apr 2024 02:48:09 GMT
Subject: RFR: 8329491: GetThreadListStackTraces function should use
 JvmtiHandshake [v2]
In-Reply-To: <kUTY9Afydr4NXD8u85_QlFMpBF531r3VvoB8X9fHLF0=.ffc34f04-b143-44ed-8f3d-a9b86d294b94@github.com>
References: <56L6f8XFyrB_cUSPTLWNIVhO0PU4w3PjRnpA5U7y_aI=.906bf099-af40-4192-a205-f84120e99ec8@github.com>
 <trwON1_yCYEqtpVxhkGJQJ2rMA7woYCInkqZ1GO1xKc=.3043e002-6d4a-4485-91f7-915515c65df9@github.com>
 <kUTY9Afydr4NXD8u85_QlFMpBF531r3VvoB8X9fHLF0=.ffc34f04-b143-44ed-8f3d-a9b86d294b94@github.com>
Message-ID: <t5qTPSf7D6r4TyzjYfzcfHYiQ8OmpBUtfJwNSzKRlpc=.29352a9e-ab5a-4cc8-a834-79c29fc4d1b6@github.com>

On Tue, 9 Apr 2024 00:56:16 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: cleanup - removed temporary logging used for debugging
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 2070:
> 
>> 2068: void
>> 2069: GetSingleStackTraceClosure::do_thread(Thread *target) {
>> 2070:   doit();
> 
> I think it makes sense to check that the target is the same as _target_jt. So we don't call it with arbitrary threads.
> or require parameter to be null if you want.
> Same for do_vthread.

Thank you for suggestion. Added asserts.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18574#discussion_r1558748415

From sspitsyn at openjdk.org  Wed Apr 10 03:17:32 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 10 Apr 2024 03:17:32 GMT
Subject: RFR: 8329491: GetThreadListStackTraces function should use
 JvmtiHandshake [v3]
In-Reply-To: <56L6f8XFyrB_cUSPTLWNIVhO0PU4w3PjRnpA5U7y_aI=.906bf099-af40-4192-a205-f84120e99ec8@github.com>
References: <56L6f8XFyrB_cUSPTLWNIVhO0PU4w3PjRnpA5U7y_aI=.906bf099-af40-4192-a205-f84120e99ec8@github.com>
Message-ID: <aJKvqwLN_-G_a-xcN7rBeyoK130gc4T9uVA4wetCMc4=.5f847e9a-cbee-415f-9303-8c25afd78635@github.com>

> The internal JVM TI `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor the JVM TI function `GetThreadListStackTraces` on the base of `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes.
> 
> Testing:
>  - Ran mach5 tiers 1-6

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

  review: add some asserts

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18574/files
  - new: https://git.openjdk.org/jdk/pull/18574/files/8f048d34..3c555b84

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

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

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

From sspitsyn at openjdk.org  Wed Apr 10 03:43:08 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 10 Apr 2024 03:43:08 GMT
Subject: RFR: 8329674: JvmtiEnvThreadState::reset_current_location function
 should use JvmtiHandshake
In-Reply-To: <uRzHmRzrIpmqOZsolHvTzUW35Gy3m8EQe7rNJjizoOY=.fbac2bc8-acfe-4520-957c-83d7450ff8ce@github.com>
References: <uRzHmRzrIpmqOZsolHvTzUW35Gy3m8EQe7rNJjizoOY=.fbac2bc8-acfe-4520-957c-83d7450ff8ce@github.com>
Message-ID: <rdUeQlCneyu6dNItoly1CnPO5vMSIkHZoK1lJyq1Ts4=.891bd6f5-8b28-4c83-843d-ac73e7fb29ae@github.com>

On Thu, 4 Apr 2024 15:28:41 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The internal JVM TI JvmtiHandshake and JvmtiUnitedHandshakeClosure classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor the JVM TI internal functions JvmtiEnvThreadState::reset_current_location on the base of JvmtiHandshake and JvmtiUnitedHandshakeClosure classes.
> 
> Testing:
>  - Ran mach5 tiers 1-6

Thank you for review, Leonid!
Refactored code as you suggested.

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

PR Comment: https://git.openjdk.org/jdk/pull/18630#issuecomment-2046487125

From sspitsyn at openjdk.org  Wed Apr 10 04:21:23 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 10 Apr 2024 04:21:23 GMT
Subject: RFR: 8329674: JvmtiEnvThreadState::reset_current_location function
 should use JvmtiHandshake [v2]
In-Reply-To: <uRzHmRzrIpmqOZsolHvTzUW35Gy3m8EQe7rNJjizoOY=.fbac2bc8-acfe-4520-957c-83d7450ff8ce@github.com>
References: <uRzHmRzrIpmqOZsolHvTzUW35Gy3m8EQe7rNJjizoOY=.fbac2bc8-acfe-4520-957c-83d7450ff8ce@github.com>
Message-ID: <zIvIwWeNVfitoFQhWAtx9CWwGQD-veZ60BgwXGAKcAs=.90406a43-321c-43f5-b739-c58e04d39ad7@github.com>

> The internal JVM TI JvmtiHandshake and JvmtiUnitedHandshakeClosure classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor the JVM TI internal functions JvmtiEnvThreadState::reset_current_location on the base of JvmtiHandshake and JvmtiUnitedHandshakeClosure classes.
> 
> Testing:
>  - Ran mach5 tiers 1-6

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

  review: refactored to get rid of overloaded doit functions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18630/files
  - new: https://git.openjdk.org/jdk/pull/18630/files/6071446f..39717f37

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

  Stats: 17 lines in 1 file changed: 5 ins; 10 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18630.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18630/head:pull/18630

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

From cjplummer at openjdk.org  Wed Apr 10 04:26:08 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 10 Apr 2024 04:26:08 GMT
Subject: RFR: JDK-8240343: JDI stopListening/stoplis001
 "FAILED: listening is successfully stopped without starting listening"
In-Reply-To: <iGvL2MQ9wvrjf5QKf9zd0LEF-KAnUZrUPXM0k3bQluE=.6cd6c780-75f9-412a-aa39-10e1b00a90a3@github.com>
References: <iGvL2MQ9wvrjf5QKf9zd0LEF-KAnUZrUPXM0k3bQluE=.6cd6c780-75f9-412a-aa39-10e1b00a90a3@github.com>
Message-ID: <pZEh1xXClmxG2xqikivfCiSfbfUiGBZwco77YF05d14=.5e3fc9d1-f410-4c89-b5fd-86a35f87d846@github.com>

On Wed, 10 Apr 2024 00:28:01 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The test starts listening on dynamic port and calls stopListening with incorrect (cArgs1) and correct (cArgs2) argument maps.
> Incorrect map is created by finding "free" port (`(new ServerSocket(0)).getLocalPort()`)
> The test fails if the same port is selected later when the listening starts.
> To avoid this free port should be picked after listening on dynamic port started.
> 
> Additionally removed unnecessary `exclusiveAccess.dirs=.` test property and incorrect comment in the description.
> The test uses `SocketListen` connectors, the coment is about `SharedMemoryListen` connector.
> 
> Testing: run the test on all Oracle-supported platforms 100 times

test/hotspot/jtreg/vmTestbase/nsk/jdi/ListeningConnector/stopListening/stoplis001.java line 98:

> 96:             log.display("TEST: start listening the address " + addr);
> 97: 
> 98:         // argHandler.getTransportPort() returns a free port (different from the listening port in cArgs2)

Suggestion:

        // argHandler.getTransportPort() returns a free port (different from the port allocated by startListen(cArgs2))

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18705#discussion_r1558821159

From cjplummer at openjdk.org  Wed Apr 10 04:31:09 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 10 Apr 2024 04:31:09 GMT
Subject: RFR: 8188784:
 javax/management/notification/BroadcasterSupportDeadlockTest.java - TEST
 FAILED: deadlock
In-Reply-To: <SjE2qD8hJjpNsEKrYBEzJm--eJ3p21uZS7M6ydlB8ow=.1bd99464-5794-4cb6-80b6-3245e8b71c39@github.com>
References: <SjE2qD8hJjpNsEKrYBEzJm--eJ3p21uZS7M6ydlB8ow=.1bd99464-5794-4cb6-80b6-3245e8b71c39@github.com>
Message-ID: <SfNnI6kzhSrCKnUCXYX4kqO_843m-2StAFcI427C1V8=.4dac2e0e-e3e1-47ed-8eaa-fa7929cde6df@github.com>

On Tue, 9 Apr 2024 11:08:31 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test incorrectly fails, although rarely, thinking its "thread 2" has deadlocked.
> A change of sleep will likely fix this, but there are other issues, so cleaning up the test a little.
> 
> Remove the probe for the ManagementFactory class, to check we are on jdk5 or later. 8-)
> 
> When sleeping, sleep 100, not 1ms, we don't need to spin fast and actually race with the other thread.
> 
> We have a 1000 iteration loop, but don't seem to use it.  We only check once then either return (pass), fail, or break (which is also fail).  Use the loop to check for the status change, which is likely what was intended.
> 
> Show the stackframes on all failures.

Looks good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18687#pullrequestreview-1990774500

From cjplummer at openjdk.org  Wed Apr 10 04:39:03 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 10 Apr 2024 04:39:03 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v10]
In-Reply-To: <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>
Message-ID: <2R7xo-H8MbEZobCgUutpcUB1nJnH85SNDWrmJBx11s0=.f24ecb7a-d890-497d-8330-5200de3b0c38@github.com>

On Wed, 27 Mar 2024 13:44:42 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently jcmd command GC.heap_dump only works with an additionally provided file name.
>> Syntax : GC.heap_dump [options] <filename>
>> 
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the <filename> is optional.
>> In case the filename is NOT set, we take the HeapDumpPath (file or directory);
>> 
>> new syntax :
>> GC.heap_dump [options] <filename> .. has precedence over second option
>> GC.heap_dump [options] ?in case -XX: HeapDumpPath=p is set
>> 
>> This would be a simplification e.g. for support cases where a filename or directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the path is intended/recommended for usage also in the jcmd case.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust java.1 man page

One other thing I just realized is that if we go through with this change, then we can't in the future change VM.heap_dump so it can be used without any filename (make it use a default filename when no filename is specified). Setting HeapDumpPath would override this default filename, and it would be really confusing to the user when suddenly heap dumps are not appearing in the default location with the default name because someone decided to specify HeapDumpPath when launching the JVM.

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2046523158

From mbaesken at openjdk.org  Wed Apr 10 13:06:12 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 10 Apr 2024 13:06:12 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v10]
In-Reply-To: <2R7xo-H8MbEZobCgUutpcUB1nJnH85SNDWrmJBx11s0=.f24ecb7a-d890-497d-8330-5200de3b0c38@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>
 <2R7xo-H8MbEZobCgUutpcUB1nJnH85SNDWrmJBx11s0=.f24ecb7a-d890-497d-8330-5200de3b0c38@github.com>
Message-ID: <qFCDe2K_QqT6qJHxMk28uScPKJuFDc0c7_C5gxAJpm0=.a0f51fa7-747f-4061-82b3-50dfed764705@github.com>

On Wed, 10 Apr 2024 04:34:53 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> One other thing I just realized is that if we go through with this change, then we can't in the future change VM.heap_dump so it can be used without any filename (make it use a default filename when no filename is specified). Setting HeapDumpPath would override this default filename, and it would be really confusing to the user when suddenly heap dumps are not appearing in the default location with the default name because someone decided to specify HeapDumpPath when launching the JVM.

Isn't this the case already for the -XX:+HeapDumpBeforeFullGC, -XX:+HeapDumpAfterFullGC  scenarios?
But probably it should be decided first if such a default is planned for VM.heap_dump .

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2047487391

From lmesnik at openjdk.org  Wed Apr 10 15:11:00 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 10 Apr 2024 15:11:00 GMT
Subject: RFR: 8329432: PopFrame and ForceEarlyReturn functions should use
 JvmtiHandshake [v2]
In-Reply-To: <4pX8bccxXZCq1XNpmOpjY4fRQ6G9TZiv_BYTlw6hIxU=.9c9fda52-ce07-40d3-9528-37c140986fe1@github.com>
References: <5tcPHZX0nNTHbQqZfHRl2riTpJglQyGJ2hRJXyIMZPY=.4de7ac6d-dd84-4943-bab1-5dba67bf5cf0@github.com>
 <4pX8bccxXZCq1XNpmOpjY4fRQ6G9TZiv_BYTlw6hIxU=.9c9fda52-ce07-40d3-9528-37c140986fe1@github.com>
Message-ID: <v0k4sDscIlgc9V43PXnEUKu6BTeQGPZekrNPdvk1beY=.be59fd96-b8fd-4008-8351-f96c4f8c3f43@github.com>

On Wed, 10 Apr 2024 02:34:37 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The internal JVM TI `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor JVM TI functions `PopFrame` and `ForceEarlyReturn` on the base of `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes.
>> 
>> Testing:
>> 
>>     Ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: remove self from args; add asserts

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18570#pullrequestreview-1991985994

From lmesnik at openjdk.org  Wed Apr 10 15:11:10 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 10 Apr 2024 15:11:10 GMT
Subject: RFR: 8329491: GetThreadListStackTraces function should use
 JvmtiHandshake [v3]
In-Reply-To: <aJKvqwLN_-G_a-xcN7rBeyoK130gc4T9uVA4wetCMc4=.5f847e9a-cbee-415f-9303-8c25afd78635@github.com>
References: <56L6f8XFyrB_cUSPTLWNIVhO0PU4w3PjRnpA5U7y_aI=.906bf099-af40-4192-a205-f84120e99ec8@github.com>
 <aJKvqwLN_-G_a-xcN7rBeyoK130gc4T9uVA4wetCMc4=.5f847e9a-cbee-415f-9303-8c25afd78635@github.com>
Message-ID: <mKtQ-VnBfJjHMiSJK3l3Pp2WiuWQu2I6WIeq5CCoS6k=.2bead283-d7bf-4f08-a17c-e8c03e334739@github.com>

On Wed, 10 Apr 2024 03:17:32 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The internal JVM TI `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor the JVM TI function `GetThreadListStackTraces` on the base of `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes.
>> 
>> Testing:
>>  - Ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: add some asserts

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18574#pullrequestreview-1991987365

From lmesnik at openjdk.org  Wed Apr 10 15:11:59 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 10 Apr 2024 15:11:59 GMT
Subject: RFR: 8329674: JvmtiEnvThreadState::reset_current_location function
 should use JvmtiHandshake [v2]
In-Reply-To: <zIvIwWeNVfitoFQhWAtx9CWwGQD-veZ60BgwXGAKcAs=.90406a43-321c-43f5-b739-c58e04d39ad7@github.com>
References: <uRzHmRzrIpmqOZsolHvTzUW35Gy3m8EQe7rNJjizoOY=.fbac2bc8-acfe-4520-957c-83d7450ff8ce@github.com>
 <zIvIwWeNVfitoFQhWAtx9CWwGQD-veZ60BgwXGAKcAs=.90406a43-321c-43f5-b739-c58e04d39ad7@github.com>
Message-ID: <3jYqwExBxKW33xaSmp_FutY8nOArPG4ZnOZ7Uo2UjQg=.0aab5ec5-ad39-405e-ac4b-199f2c07116a@github.com>

On Wed, 10 Apr 2024 04:21:23 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The internal JVM TI JvmtiHandshake and JvmtiUnitedHandshakeClosure classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor the JVM TI internal functions JvmtiEnvThreadState::reset_current_location on the base of JvmtiHandshake and JvmtiUnitedHandshakeClosure classes.
>> 
>> Testing:
>>  - Ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: refactored to get rid of overloaded doit functions

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18630#pullrequestreview-1991988172

From amenkov at openjdk.org  Wed Apr 10 17:36:32 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 10 Apr 2024 17:36:32 GMT
Subject: RFR: JDK-8240343: JDI stopListening/stoplis001
 "FAILED: listening is successfully stopped without starting listening" [v2]
In-Reply-To: <iGvL2MQ9wvrjf5QKf9zd0LEF-KAnUZrUPXM0k3bQluE=.6cd6c780-75f9-412a-aa39-10e1b00a90a3@github.com>
References: <iGvL2MQ9wvrjf5QKf9zd0LEF-KAnUZrUPXM0k3bQluE=.6cd6c780-75f9-412a-aa39-10e1b00a90a3@github.com>
Message-ID: <XjGts1DnTzhfuPq7RbkaindOZqJyllrHqAvXkV2vnXc=.1a975d46-9069-405f-a8b0-3f87dcce6390@github.com>

> The test starts listening on dynamic port and calls stopListening with incorrect (cArgs1) and correct (cArgs2) argument maps.
> Incorrect map is created by finding "free" port (`(new ServerSocket(0)).getLocalPort()`)
> The test fails if the same port is selected later when the listening starts.
> To avoid this free port should be picked after listening on dynamic port started.
> 
> Additionally removed unnecessary `exclusiveAccess.dirs=.` test property and incorrect comment in the description.
> The test uses `SocketListen` connectors, the coment is about `SharedMemoryListen` connector.
> 
> Testing: run the test on all Oracle-supported platforms 100 times

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  Update test/hotspot/jtreg/vmTestbase/nsk/jdi/ListeningConnector/stopListening/stoplis001.java
  
  Co-authored-by: Chris Plummer <chris.plummer at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18705/files
  - new: https://git.openjdk.org/jdk/pull/18705/files/3f9bc6b7..3b0d5540

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

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

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

From amenkov at openjdk.org  Wed Apr 10 17:36:32 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 10 Apr 2024 17:36:32 GMT
Subject: RFR: JDK-8240343: JDI stopListening/stoplis001
 "FAILED: listening is successfully stopped without starting listening" [v2]
In-Reply-To: <pZEh1xXClmxG2xqikivfCiSfbfUiGBZwco77YF05d14=.5e3fc9d1-f410-4c89-b5fd-86a35f87d846@github.com>
References: <iGvL2MQ9wvrjf5QKf9zd0LEF-KAnUZrUPXM0k3bQluE=.6cd6c780-75f9-412a-aa39-10e1b00a90a3@github.com>
 <pZEh1xXClmxG2xqikivfCiSfbfUiGBZwco77YF05d14=.5e3fc9d1-f410-4c89-b5fd-86a35f87d846@github.com>
Message-ID: <PIY_Zr0X7i4VAmjxPUgFL24heO4wyoODbt98Z66x8P8=.a9849e7f-917d-4e7e-8ee5-e994bf8d4fe2@github.com>

On Wed, 10 Apr 2024 04:23:30 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test/hotspot/jtreg/vmTestbase/nsk/jdi/ListeningConnector/stopListening/stoplis001.java
>>   
>>   Co-authored-by: Chris Plummer <chris.plummer at oracle.com>
>
> test/hotspot/jtreg/vmTestbase/nsk/jdi/ListeningConnector/stopListening/stoplis001.java line 98:
> 
>> 96:             log.display("TEST: start listening the address " + addr);
>> 97: 
>> 98:         // argHandler.getTransportPort() returns a free port (different from the listening port in cArgs2)
> 
> Suggestion:
> 
>         // argHandler.getTransportPort() returns a free port (different from the port allocated by startListen(cArgs2))

done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18705#discussion_r1559838917

From cjplummer at openjdk.org  Wed Apr 10 17:48:14 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 10 Apr 2024 17:48:14 GMT
Subject: RFR: JDK-8327769: jcmd GC.heap_dump without options should write
 to location given by -XX:HeapDumpPath, if set [v10]
In-Reply-To: <qFCDe2K_QqT6qJHxMk28uScPKJuFDc0c7_C5gxAJpm0=.a0f51fa7-747f-4061-82b3-50dfed764705@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>
 <2R7xo-H8MbEZobCgUutpcUB1nJnH85SNDWrmJBx11s0=.f24ecb7a-d890-497d-8330-5200de3b0c38@github.com>
 <qFCDe2K_QqT6qJHxMk28uScPKJuFDc0c7_C5gxAJpm0=.a0f51fa7-747f-4061-82b3-50dfed764705@github.com>
Message-ID: <s4v2xgmCY3vESeArzCF0SxCVQjiBjEaWVBE-S04VfRU=.54ec7db4-4883-416f-aad3-5c45ed673c47@github.com>

On Wed, 10 Apr 2024 13:03:40 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > One other thing I just realized is that if we go through with this change, then we can't in the future change VM.heap_dump so it can be used without any filename (make it use a default filename when no filename is specified). Setting HeapDumpPath would override this default filename, and it would be really confusing to the user when suddenly heap dumps are not appearing in the default location with the default name because someone decided to specify HeapDumpPath when launching the JVM.
> 
> Isn't this the case already for the -XX:+HeapDumpBeforeFullGC, -XX:+HeapDumpAfterFullGC scenarios? But probably it should be decided first if such a default is planned for VM.heap_dump .

I don't think so, but maybe I'm misunderstanding your point. It may be desirable to have VM.heap_dump support not specifying a filename and instead just have it choose a default name and path, probably the current working directory with a name something like java_pid<pid>.hprof. However, having this default and also using HeapDumpPath if set conflict with each other. Someone could be relying on the VM.heap_dump default, and then suddenly that default is no longer honored because HeapDumpPath was added to the command line. I don't see -XX:+HeapDumpBeforeFullGC or -XX:+HeapDumpAfterFullGC playing a roll in this scenario.

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2048132997

From cjplummer at openjdk.org  Wed Apr 10 18:00:10 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 10 Apr 2024 18:00:10 GMT
Subject: RFR: JDK-8240343: JDI stopListening/stoplis001
 "FAILED: listening is successfully stopped without starting listening" [v2]
In-Reply-To: <XjGts1DnTzhfuPq7RbkaindOZqJyllrHqAvXkV2vnXc=.1a975d46-9069-405f-a8b0-3f87dcce6390@github.com>
References: <iGvL2MQ9wvrjf5QKf9zd0LEF-KAnUZrUPXM0k3bQluE=.6cd6c780-75f9-412a-aa39-10e1b00a90a3@github.com>
 <XjGts1DnTzhfuPq7RbkaindOZqJyllrHqAvXkV2vnXc=.1a975d46-9069-405f-a8b0-3f87dcce6390@github.com>
Message-ID: <CUtCCf_-sahwnxEuWQT0NwnvcMKATZE_EzEKqLH4Ib8=.2dffba7f-8163-40df-accf-94e016956935@github.com>

On Wed, 10 Apr 2024 17:36:32 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The test starts listening on dynamic port and calls stopListening with incorrect (cArgs1) and correct (cArgs2) argument maps.
>> Incorrect map is created by finding "free" port (`(new ServerSocket(0)).getLocalPort()`)
>> The test fails if the same port is selected later when the listening starts.
>> To avoid this free port should be picked after listening on dynamic port started.
>> 
>> Additionally removed unnecessary `exclusiveAccess.dirs=.` test property and incorrect comment in the description.
>> The test uses `SocketListen` connectors, the coment is about `SharedMemoryListen` connector.
>> 
>> Testing: run the test on all Oracle-supported platforms 100 times
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/hotspot/jtreg/vmTestbase/nsk/jdi/ListeningConnector/stopListening/stoplis001.java
>   
>   Co-authored-by: Chris Plummer <chris.plummer at oracle.com>

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18705#pullrequestreview-1992356328

From sspitsyn at openjdk.org  Wed Apr 10 20:27:18 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 10 Apr 2024 20:27:18 GMT
Subject: RFR: 8329432: PopFrame and ForceEarlyReturn functions should use
 JvmtiHandshake [v2]
In-Reply-To: <4pX8bccxXZCq1XNpmOpjY4fRQ6G9TZiv_BYTlw6hIxU=.9c9fda52-ce07-40d3-9528-37c140986fe1@github.com>
References: <5tcPHZX0nNTHbQqZfHRl2riTpJglQyGJ2hRJXyIMZPY=.4de7ac6d-dd84-4943-bab1-5dba67bf5cf0@github.com>
 <4pX8bccxXZCq1XNpmOpjY4fRQ6G9TZiv_BYTlw6hIxU=.9c9fda52-ce07-40d3-9528-37c140986fe1@github.com>
Message-ID: <A_Mvnx1IM-VhD-fMVDFrnqOlt1V0DumrvKKPyk3CAjo=.5bc097a5-89ea-49c5-b237-2efd5ac14efb@github.com>

On Wed, 10 Apr 2024 02:34:37 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The internal JVM TI `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor JVM TI functions `PopFrame` and `ForceEarlyReturn` on the base of `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes.
>> 
>> Testing:
>> 
>>     Ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: remove self from args; add asserts

Leonid, thank you for review!

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

PR Comment: https://git.openjdk.org/jdk/pull/18570#issuecomment-2048376644

From sspitsyn at openjdk.org  Wed Apr 10 20:28:17 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 10 Apr 2024 20:28:17 GMT
Subject: RFR: 8329491: GetThreadListStackTraces function should use
 JvmtiHandshake [v3]
In-Reply-To: <aJKvqwLN_-G_a-xcN7rBeyoK130gc4T9uVA4wetCMc4=.5f847e9a-cbee-415f-9303-8c25afd78635@github.com>
References: <56L6f8XFyrB_cUSPTLWNIVhO0PU4w3PjRnpA5U7y_aI=.906bf099-af40-4192-a205-f84120e99ec8@github.com>
 <aJKvqwLN_-G_a-xcN7rBeyoK130gc4T9uVA4wetCMc4=.5f847e9a-cbee-415f-9303-8c25afd78635@github.com>
Message-ID: <R4KZs1qBiKRfHyRR4sEO-92eaS6si6qCO7FCgy1-5Yo=.88e108bf-67d0-454e-a142-5fa8c8e56cf5@github.com>

On Wed, 10 Apr 2024 03:17:32 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The internal JVM TI `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor the JVM TI function `GetThreadListStackTraces` on the base of `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes.
>> 
>> Testing:
>>  - Ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: add some asserts

Leonid, thank you for review!

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

PR Comment: https://git.openjdk.org/jdk/pull/18574#issuecomment-2048377357

From sspitsyn at openjdk.org  Thu Apr 11 01:18:57 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 11 Apr 2024 01:18:57 GMT
Subject: Integrated: 8329432: PopFrame and ForceEarlyReturn functions should
 use JvmtiHandshake
In-Reply-To: <5tcPHZX0nNTHbQqZfHRl2riTpJglQyGJ2hRJXyIMZPY=.4de7ac6d-dd84-4943-bab1-5dba67bf5cf0@github.com>
References: <5tcPHZX0nNTHbQqZfHRl2riTpJglQyGJ2hRJXyIMZPY=.4de7ac6d-dd84-4943-bab1-5dba67bf5cf0@github.com>
Message-ID: <QrL5fn0YQ8SOoWohgzz-pVyRpUApveHl_8PaC_whF_k=.0cdecdd8-20ac-4e3e-acf9-38a179411ba7@github.com>

On Tue, 2 Apr 2024 00:22:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The internal JVM TI `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor JVM TI functions `PopFrame` and `ForceEarlyReturn` on the base of `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes.
> 
> Testing:
> 
>     Ran mach5 tiers 1-6

This pull request has now been integrated.

Changeset: 643dd48a
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/643dd48a2aa05388c55fa728a22885540b967a05
Stats:     45 lines in 3 files changed: 15 ins; 20 del; 10 mod

8329432: PopFrame and ForceEarlyReturn functions should use JvmtiHandshake

Reviewed-by: pchilanomate, lmesnik

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

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

From sspitsyn at openjdk.org  Thu Apr 11 04:21:45 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 11 Apr 2024 04:21:45 GMT
Subject: Integrated: 8329491: GetThreadListStackTraces function should use
 JvmtiHandshake
In-Reply-To: <56L6f8XFyrB_cUSPTLWNIVhO0PU4w3PjRnpA5U7y_aI=.906bf099-af40-4192-a205-f84120e99ec8@github.com>
References: <56L6f8XFyrB_cUSPTLWNIVhO0PU4w3PjRnpA5U7y_aI=.906bf099-af40-4192-a205-f84120e99ec8@github.com>
Message-ID: <l82Svyx-iGOCUq-RdbEKVChbJeWzXRwORnnzTqZxHVY=.9559e619-907d-473b-a9a3-27211486e857@github.com>

On Tue, 2 Apr 2024 08:13:20 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The internal JVM TI `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor the JVM TI function `GetThreadListStackTraces` on the base of `JvmtiHandshake` and `JvmtiUnitedHandshakeClosure` classes.
> 
> Testing:
>  - Ran mach5 tiers 1-6

This pull request has now been integrated.

Changeset: 5e544f15
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5e544f15100366f4e2db58cb0e28cdfd292fe35f
Stats:     43 lines in 3 files changed: 17 ins; 19 del; 7 mod

8329491: GetThreadListStackTraces function should use JvmtiHandshake

Reviewed-by: pchilanomate, lmesnik

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

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

From lujaniuk at openjdk.org  Thu Apr 11 07:12:20 2024
From: lujaniuk at openjdk.org (Ludvig Janiuk)
Date: Thu, 11 Apr 2024 07:12:20 GMT
Subject: RFR: 8329774: Break long lines in jdk/src/jdk.hotspot.agent/doc
 /transported_core.html [v2]
In-Reply-To: <I5Aydb87FJO2kw3amedisLKUmd2K4v22UZAtFn5bhV8=.9dac1556-0acf-4239-817c-05e202d557b6@github.com>
References: <I5Aydb87FJO2kw3amedisLKUmd2K4v22UZAtFn5bhV8=.9dac1556-0acf-4239-817c-05e202d557b6@github.com>
Message-ID: <hvsSiE5r20mv7xcxEykaOcEcKG9Oq3x7uTcYN0BkAG4=.73369f2e-4178-4397-b6eb-45ee4ef997bd@github.com>

> I used "fold -sw 120" and removed trailing whitespaces.

Ludvig Janiuk has updated the pull request incrementally with three additional commits since the last revision:

 - prepends
 - fold 100
 - Revert "8329774 Break long lines in jdk/src/jdk.hotspot.agent/doc /transported_core.html"
   
   This reverts commit 12346b1b178e7ac3b1fbaddec76890f05edb9525.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18654/files
  - new: https://git.openjdk.org/jdk/pull/18654/files/12346b1b..b722c9b5

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

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

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

From lujaniuk at openjdk.org  Thu Apr 11 07:12:20 2024
From: lujaniuk at openjdk.org (Ludvig Janiuk)
Date: Thu, 11 Apr 2024 07:12:20 GMT
Subject: RFR: 8329774: Break long lines in jdk/src/jdk.hotspot.agent/doc
 /transported_core.html
In-Reply-To: <I5Aydb87FJO2kw3amedisLKUmd2K4v22UZAtFn5bhV8=.9dac1556-0acf-4239-817c-05e202d557b6@github.com>
References: <I5Aydb87FJO2kw3amedisLKUmd2K4v22UZAtFn5bhV8=.9dac1556-0acf-4239-817c-05e202d557b6@github.com>
Message-ID: <vE6VZVdO5V5OWqGiVT0GB_0axgpVQ7qmo7gWblx2fjs=.2c0f4da3-2357-40a2-a592-bc23289e88d0@github.com>

On Fri, 5 Apr 2024 12:50:04 GMT, Ludvig Janiuk <lujaniuk at openjdk.org> wrote:

> I used "fold -sw 120" and removed trailing whitespaces.

I followed your suggestion, and also fixed a typo.

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

PR Comment: https://git.openjdk.org/jdk/pull/18654#issuecomment-2049055211

From kevinw at openjdk.org  Thu Apr 11 08:44:42 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 11 Apr 2024 08:44:42 GMT
Subject: RFR: 8329774: Break long lines in jdk/src/jdk.hotspot.agent/doc
 /transported_core.html [v2]
In-Reply-To: <hvsSiE5r20mv7xcxEykaOcEcKG9Oq3x7uTcYN0BkAG4=.73369f2e-4178-4397-b6eb-45ee4ef997bd@github.com>
References: <I5Aydb87FJO2kw3amedisLKUmd2K4v22UZAtFn5bhV8=.9dac1556-0acf-4239-817c-05e202d557b6@github.com>
 <hvsSiE5r20mv7xcxEykaOcEcKG9Oq3x7uTcYN0BkAG4=.73369f2e-4178-4397-b6eb-45ee4ef997bd@github.com>
Message-ID: <RY5podW8nrNUBCbkEQyW5HFSNk_CRoOi2IFrIbkXafs=.72a305a5-8688-49f3-9928-3835bbe24de8@github.com>

On Thu, 11 Apr 2024 07:12:20 GMT, Ludvig Janiuk <lujaniuk at openjdk.org> wrote:

>> I used "fold -sw 120" and removed trailing whitespaces.
>
> Ludvig Janiuk has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - prepends
>  - fold 100
>  - Revert "8329774 Break long lines in jdk/src/jdk.hotspot.agent/doc /transported_core.html"
>    
>    This reverts commit 12346b1b178e7ac3b1fbaddec76890f05edb9525.

Looks good to me!

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18654#pullrequestreview-1993615107

From sgehwolf at openjdk.org  Thu Apr 11 09:35:44 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 11 Apr 2024 09:35:44 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container
In-Reply-To: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
Message-ID: <DpCaI_OsPiqyJVu9yrrU-g4Zo4_qsd_sHeaAnzsuUCY=.8a42d36b-7e3f-41f2-b7a2-fa733fb08fea@github.com>

On Mon, 11 Mar 2024 16:55:36 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this enhancement to the container detection code which allows it to figure out whether the JVM is actually running inside a container (`podman`, `docker`, `crio`), or with some other means that enforces memory/cpu limits by means of the cgroup filesystem. If neither of those conditions hold, the JVM runs in not containerized mode, addressing the issue described in the JBS tracker. For example, on my Linux system `is_containerized() == false" is being indicated with the following trace log line:
> 
> 
> [0.001s][debug][os,container] OSContainer::init: is_containerized() = false because no cpu or memory limit is present
> 
> 
> This state is being exposed by the Java `Metrics` API class using the new (still JDK internal) `isContainerized()` method. Example:
> 
> 
> java -XshowSettings:system --version
> Operating System Metrics:
>     Provider: cgroupv1
>     System not containerized.
> openjdk 23-internal 2024-09-17
> OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk)
> OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)
> 
> 
> The basic property this is being built on is the observation that the cgroup controllers typically get mounted read only into containers. Note that the current container tests assert that `OSContainer::is_containerized() == true` in various tests. Therefore, using the heuristic of "is any memory or cpu limit present" isn't sufficient. I had considered that in an earlier iteration, but many container tests failed.
> 
> Overall, I think, with this patch we improve the current situation of claiming a containerized system being present when it's actually just a regular Linux system.
> 
> Testing:
> 
> - [x] GHA (risc-v failure seems infra related)
> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including gtests)
> - [x] Some manual testing using cri-o
> 
> Thoughts?

Gentle ping.

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

PR Comment: https://git.openjdk.org/jdk/pull/18201#issuecomment-2049297883

From lujaniuk at openjdk.org  Thu Apr 11 10:35:46 2024
From: lujaniuk at openjdk.org (Ludvig Janiuk)
Date: Thu, 11 Apr 2024 10:35:46 GMT
Subject: Integrated: 8329774: Break long lines in jdk/src/jdk.hotspot.agent/doc
 /transported_core.html
In-Reply-To: <I5Aydb87FJO2kw3amedisLKUmd2K4v22UZAtFn5bhV8=.9dac1556-0acf-4239-817c-05e202d557b6@github.com>
References: <I5Aydb87FJO2kw3amedisLKUmd2K4v22UZAtFn5bhV8=.9dac1556-0acf-4239-817c-05e202d557b6@github.com>
Message-ID: <VoxyRSvrGOveu4S_R7Mx8yWfgYruD0t3MSOmXi8qXUI=.d86faab2-557a-4bfe-9232-64322dfd6460@github.com>

On Fri, 5 Apr 2024 12:50:04 GMT, Ludvig Janiuk <lujaniuk at openjdk.org> wrote:

> I used "fold -sw 120" and removed trailing whitespaces.

This pull request has now been integrated.

Changeset: 9acce7a6
Author:    Ludvig Janiuk <lujaniuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9acce7a6f326543c302ca0408213cf333f5f778a
Stats:     16 lines in 1 file changed: 10 ins; 0 del; 6 mod

8329774: Break long lines in jdk/src/jdk.hotspot.agent/doc /transported_core.html

Reviewed-by: kevinw

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

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

From sgehwolf at openjdk.org  Thu Apr 11 12:08:02 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 11 Apr 2024 12:08:02 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v2]
In-Reply-To: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
Message-ID: <trUwK5rQzvQtPnGLg7PeAvOdtPfJHFpEKdtyJcLj6Bw=.2435ad46-f513-4f20-952d-70c1b1f24924@github.com>

> Please review this enhancement to the container detection code which allows it to figure out whether the JVM is actually running inside a container (`podman`, `docker`, `crio`), or with some other means that enforces memory/cpu limits by means of the cgroup filesystem. If neither of those conditions hold, the JVM runs in not containerized mode, addressing the issue described in the JBS tracker. For example, on my Linux system `is_containerized() == false" is being indicated with the following trace log line:
> 
> 
> [0.001s][debug][os,container] OSContainer::init: is_containerized() = false because no cpu or memory limit is present
> 
> 
> This state is being exposed by the Java `Metrics` API class using the new (still JDK internal) `isContainerized()` method. Example:
> 
> 
> java -XshowSettings:system --version
> Operating System Metrics:
>     Provider: cgroupv1
>     System not containerized.
> openjdk 23-internal 2024-09-17
> OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk)
> OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)
> 
> 
> The basic property this is being built on is the observation that the cgroup controllers typically get mounted read only into containers. Note that the current container tests assert that `OSContainer::is_containerized() == true` in various tests. Therefore, using the heuristic of "is any memory or cpu limit present" isn't sufficient. I had considered that in an earlier iteration, but many container tests failed.
> 
> Overall, I think, with this patch we improve the current situation of claiming a containerized system being present when it's actually just a regular Linux system.
> 
> Testing:
> 
> - [x] GHA (risc-v failure seems infra related)
> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including gtests)
> - [x] Some manual testing using cri-o
> 
> Thoughts?

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 ten additional commits since the last revision:

 - Merge branch 'master' into jdk-8261242-is-containerized-fix
 - jcheck fixes
 - Fix tests
 - Implement Metrics.isContainerized()
 - Some clean-up
 - Drop cgroups testing on plain Linux
 - Implement fall-back logic for non-ro controller mounts
 - Make find_ro static and local to compilation unit
 - 8261242: [Linux] OSContainer::is_containerized() returns true

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18201/files
  - new: https://git.openjdk.org/jdk/pull/18201/files/98325f18..0df26ebd

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

  Stats: 407791 lines in 3887 files changed: 43423 ins; 33650 del; 330718 mod
  Patch: https://git.openjdk.org/jdk/pull/18201.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18201/head:pull/18201

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

From sspitsyn at openjdk.org  Thu Apr 11 14:23:42 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 11 Apr 2024 14:23:42 GMT
Subject: RFR: 8240343: JDI stopListening/stoplis001
 "FAILED: listening is successfully stopped without starting listening" [v2]
In-Reply-To: <XjGts1DnTzhfuPq7RbkaindOZqJyllrHqAvXkV2vnXc=.1a975d46-9069-405f-a8b0-3f87dcce6390@github.com>
References: <iGvL2MQ9wvrjf5QKf9zd0LEF-KAnUZrUPXM0k3bQluE=.6cd6c780-75f9-412a-aa39-10e1b00a90a3@github.com>
 <XjGts1DnTzhfuPq7RbkaindOZqJyllrHqAvXkV2vnXc=.1a975d46-9069-405f-a8b0-3f87dcce6390@github.com>
Message-ID: <BJnxJy00yy8K1V0z85g_zhozrbMVFEINbY-uykxaNl8=.48299c81-b6c1-4ff4-bf64-fabebb79e632@github.com>

On Wed, 10 Apr 2024 17:36:32 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The test starts listening on dynamic port and calls stopListening with incorrect (cArgs1) and correct (cArgs2) argument maps.
>> Incorrect map is created by finding "free" port (`(new ServerSocket(0)).getLocalPort()`)
>> The test fails if the same port is selected later when the listening starts.
>> To avoid this free port should be picked after listening on dynamic port started.
>> 
>> Additionally removed unnecessary `exclusiveAccess.dirs=.` test property and incorrect comment in the description.
>> The test uses `SocketListen` connectors, the coment is about `SharedMemoryListen` connector.
>> 
>> Testing: run the test on all Oracle-supported platforms 100 times
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/hotspot/jtreg/vmTestbase/nsk/jdi/ListeningConnector/stopListening/stoplis001.java
>   
>   Co-authored-by: Chris Plummer <chris.plummer at oracle.com>

Looks good to me.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18705#pullrequestreview-1994337775

From larry.cable at oracle.com  Thu Apr 11 14:42:31 2024
From: larry.cable at oracle.com (Laurence Cable)
Date: Thu, 11 Apr 2024 07:42:31 -0700
Subject: Fwd: RFO: a tool to analyze HotSpot fatal error logs
In-Reply-To: <CAG0Tb0iiDxhLuG1Bkg=8xusAUyoX9ZyKt64rnP22Sau9LNvWJw@mail.gmail.com>
References: <CAG0Tb0iiDxhLuG1Bkg=8xusAUyoX9ZyKt64rnP22Sau9LNvWJw@mail.gmail.com>
Message-ID: <c6186c10-7691-4d00-a4b7-af4643345950@oracle.com>




-------- Forwarded Message --------
Subject: 	RFO: a tool to analyze HotSpot fatal error logs
Date: 	Thu, 11 Apr 2024 18:05:44 +0400
From: 	Maxim Kartashev <maxim.kartashev at jetbrains.com>
To: 	discuss at openjdk.org, hotspot-dev at openjdk.org



Hello,

I am writing to inquire about the potential interest of the people 
involved in inspecting HotSpot crashes in a tool aimed at facilitating 
that inspection.

We at JetBrains have developed an internal plugin that helps both with 
filtering through dozens of reports quickly in order to find a pattern 
and for diving deep into a particular crash. In addition to the 
"standard" features such as syntax highlighting, folding, and structural 
navigation, it will
* highlight potential problems such as overloaded CPU, low physical 
memory, the presence of OOME in the recent exceptions, LD_LIBRARY_PATH 
being set, etc,
* generate an "executive summary" for a high-level overview, for 
example, by front-line support,
* pop up a tooltip for any recognized address describing its origin (for 
example, if it belongs to some thread's stack, the Java heap, a 
register, or a memory-mapped region),
* provide the ability to highlight all addresses "near" the selected 
address, including registers, threads, and memory-mapped regions.

If there is sufficient interest in creating a public and/or open-source 
variant of this internal plugin, I will pitch the idea to my employer. 
It shouldn't be too much work to create a public version.

Kind regards,
Maxim.

References:
* https://docs.oracle.com/javase/10/troubleshoot/fatal-error-log.htm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20240411/9ec7e73e/attachment.htm>

From pchilanomate at openjdk.org  Thu Apr 11 16:34:46 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 11 Apr 2024 16:34:46 GMT
Subject: RFR: 8329674: JvmtiEnvThreadState::reset_current_location function
 should use JvmtiHandshake [v2]
In-Reply-To: <zIvIwWeNVfitoFQhWAtx9CWwGQD-veZ60BgwXGAKcAs=.90406a43-321c-43f5-b739-c58e04d39ad7@github.com>
References: <uRzHmRzrIpmqOZsolHvTzUW35Gy3m8EQe7rNJjizoOY=.fbac2bc8-acfe-4520-957c-83d7450ff8ce@github.com>
 <zIvIwWeNVfitoFQhWAtx9CWwGQD-veZ60BgwXGAKcAs=.90406a43-321c-43f5-b739-c58e04d39ad7@github.com>
Message-ID: <10EU-jvOhZaur5uqCtnBJVodhqV8MKLzfI7IGBfo0cg=.348e71d1-0394-41fe-b511-3f3d7a35713c@github.com>

On Wed, 10 Apr 2024 04:21:23 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The internal JVM TI JvmtiHandshake and JvmtiUnitedHandshakeClosure classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor the JVM TI internal functions JvmtiEnvThreadState::reset_current_location on the base of JvmtiHandshake and JvmtiUnitedHandshakeClosure classes.
>> 
>> Testing:
>>  - Ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: refactored to get rid of overloaded doit functions

Looks good to me, just a few comments.

src/hotspot/share/prims/jvmtiEnvThreadState.cpp line 307:

> 305:     if (!JvmtiEnvBase::is_vthread_alive(target_h())) {
> 306:       return; // _completed remains false.
> 307:     }

Do we need this? We already do this check in JvmtiHandshake::execute().

src/hotspot/share/prims/jvmtiEnvThreadState.cpp line 309:

> 307:     }
> 308:     ResourceMark rm;
> 309:     javaVFrame *jvf = JvmtiEnvBase::get_vthread_jvf(target_h());

This method already handles both mounted and unmounted case, so do we need the first conditional above?

src/hotspot/share/prims/jvmtiEnvThreadState.cpp line 367:

> 365:       GetCurrentLocationClosure op;
> 366:       JvmtiHandshake::execute(&op, &tlh, thread, thread_h);
> 367: 

Seems we are missing a JvmtiVTMSTransitionDisabler.

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

PR Review: https://git.openjdk.org/jdk/pull/18630#pullrequestreview-1994658919
PR Review Comment: https://git.openjdk.org/jdk/pull/18630#discussion_r1561295746
PR Review Comment: https://git.openjdk.org/jdk/pull/18630#discussion_r1561298952
PR Review Comment: https://git.openjdk.org/jdk/pull/18630#discussion_r1561300541

From jjg at openjdk.org  Thu Apr 11 20:55:24 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 11 Apr 2024 20:55:24 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v2]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <au6_FZORG1xVh5VnfoMMR60a_2oa1qny0ElKeIGpvFI=.94ed31a5-a875-4bc6-927b-da0f512ad43e@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  adjust call for `saveDanglingDocComments` for enum members

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18527/files
  - new: https://git.openjdk.org/jdk/pull/18527/files/3d6f1f95..56d6dcac

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

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

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

From sspitsyn at openjdk.org  Thu Apr 11 22:19:41 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 11 Apr 2024 22:19:41 GMT
Subject: RFR: 8329674: JvmtiEnvThreadState::reset_current_location function
 should use JvmtiHandshake [v2]
In-Reply-To: <10EU-jvOhZaur5uqCtnBJVodhqV8MKLzfI7IGBfo0cg=.348e71d1-0394-41fe-b511-3f3d7a35713c@github.com>
References: <uRzHmRzrIpmqOZsolHvTzUW35Gy3m8EQe7rNJjizoOY=.fbac2bc8-acfe-4520-957c-83d7450ff8ce@github.com>
 <zIvIwWeNVfitoFQhWAtx9CWwGQD-veZ60BgwXGAKcAs=.90406a43-321c-43f5-b739-c58e04d39ad7@github.com>
 <10EU-jvOhZaur5uqCtnBJVodhqV8MKLzfI7IGBfo0cg=.348e71d1-0394-41fe-b511-3f3d7a35713c@github.com>
Message-ID: <V9N-qKlPiIrVlO8YtHxaQnRFYPhdXX_WDGFXK2zn_98=.e1667ddc-e3c9-497e-a06b-04585d8a87f6@github.com>

On Thu, 11 Apr 2024 16:22:44 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: refactored to get rid of overloaded doit functions
>
> src/hotspot/share/prims/jvmtiEnvThreadState.cpp line 307:
> 
>> 305:     if (!JvmtiEnvBase::is_vthread_alive(target_h())) {
>> 306:       return; // _completed remains false.
>> 307:     }
> 
> Do we need this? We already do this check in JvmtiHandshake::execute().

Good suggestion, thanks. Will remove it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18630#discussion_r1561812235

From sspitsyn at openjdk.org  Thu Apr 11 22:27:42 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 11 Apr 2024 22:27:42 GMT
Subject: RFR: 8329674: JvmtiEnvThreadState::reset_current_location function
 should use JvmtiHandshake [v2]
In-Reply-To: <10EU-jvOhZaur5uqCtnBJVodhqV8MKLzfI7IGBfo0cg=.348e71d1-0394-41fe-b511-3f3d7a35713c@github.com>
References: <uRzHmRzrIpmqOZsolHvTzUW35Gy3m8EQe7rNJjizoOY=.fbac2bc8-acfe-4520-957c-83d7450ff8ce@github.com>
 <zIvIwWeNVfitoFQhWAtx9CWwGQD-veZ60BgwXGAKcAs=.90406a43-321c-43f5-b739-c58e04d39ad7@github.com>
 <10EU-jvOhZaur5uqCtnBJVodhqV8MKLzfI7IGBfo0cg=.348e71d1-0394-41fe-b511-3f3d7a35713c@github.com>
Message-ID: <JjllBlH-erQwV0GUXg-hl1YR8CdOzmCFOrmR9x-8Qdo=.95283e45-61ae-4c15-84ec-6016db843f4b@github.com>

On Thu, 11 Apr 2024 16:25:30 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: refactored to get rid of overloaded doit functions
>
> src/hotspot/share/prims/jvmtiEnvThreadState.cpp line 309:
> 
>> 307:     }
>> 308:     ResourceMark rm;
>> 309:     javaVFrame *jvf = JvmtiEnvBase::get_vthread_jvf(target_h());
> 
> This method already handles both mounted and unmounted case, so do we need the first conditional above?

Good suggestion, thanks.
I was also thinking about it but decided to avoid the risk because of this check in `do_thread()`:

    if (!jt->is_exiting() && jt->has_last_Java_frame()) {

It can be it is not important to check or I can add an assert for this condition. Let me try and test it first.
This kind of simplification looks as important.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18630#discussion_r1561816846

From sspitsyn at openjdk.org  Thu Apr 11 22:56:42 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 11 Apr 2024 22:56:42 GMT
Subject: RFR: 8329674: JvmtiEnvThreadState::reset_current_location function
 should use JvmtiHandshake [v2]
In-Reply-To: <10EU-jvOhZaur5uqCtnBJVodhqV8MKLzfI7IGBfo0cg=.348e71d1-0394-41fe-b511-3f3d7a35713c@github.com>
References: <uRzHmRzrIpmqOZsolHvTzUW35Gy3m8EQe7rNJjizoOY=.fbac2bc8-acfe-4520-957c-83d7450ff8ce@github.com>
 <zIvIwWeNVfitoFQhWAtx9CWwGQD-veZ60BgwXGAKcAs=.90406a43-321c-43f5-b739-c58e04d39ad7@github.com>
 <10EU-jvOhZaur5uqCtnBJVodhqV8MKLzfI7IGBfo0cg=.348e71d1-0394-41fe-b511-3f3d7a35713c@github.com>
Message-ID: <I3-FWexMuiNfgYZCUpB70ADoSbe30vqPoyTW_XaK3PI=.8f8649dc-6600-47da-a120-4be552b5eb87@github.com>

On Thu, 11 Apr 2024 16:26:51 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: refactored to get rid of overloaded doit functions
>
> src/hotspot/share/prims/jvmtiEnvThreadState.cpp line 367:
> 
>> 365:       GetCurrentLocationClosure op;
>> 366:       JvmtiHandshake::execute(&op, &tlh, thread, thread_h);
>> 367: 
> 
> Seems we are missing a JvmtiVTMSTransitionDisabler.

Good question, thanks.
The `JvmtiVTMSTransitionDisabler` is supposed to be installed in the caller's context if needed.
However, it is not easy to make sure it is always the case.
At least, I see a couple of contexts when the `JvmtiVTMSTransitionDisabler` is not being installed.
But it is not clear if it is really needed there. Let me do some extra analysis there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18630#discussion_r1561834120

From sspitsyn at openjdk.org  Fri Apr 12 01:24:52 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 12 Apr 2024 01:24:52 GMT
Subject: RFR: 8329674: JvmtiEnvThreadState::reset_current_location function
 should use JvmtiHandshake [v2]
In-Reply-To: <I3-FWexMuiNfgYZCUpB70ADoSbe30vqPoyTW_XaK3PI=.8f8649dc-6600-47da-a120-4be552b5eb87@github.com>
References: <uRzHmRzrIpmqOZsolHvTzUW35Gy3m8EQe7rNJjizoOY=.fbac2bc8-acfe-4520-957c-83d7450ff8ce@github.com>
 <zIvIwWeNVfitoFQhWAtx9CWwGQD-veZ60BgwXGAKcAs=.90406a43-321c-43f5-b739-c58e04d39ad7@github.com>
 <10EU-jvOhZaur5uqCtnBJVodhqV8MKLzfI7IGBfo0cg=.348e71d1-0394-41fe-b511-3f3d7a35713c@github.com>
 <I3-FWexMuiNfgYZCUpB70ADoSbe30vqPoyTW_XaK3PI=.8f8649dc-6600-47da-a120-4be552b5eb87@github.com>
Message-ID: <6hM-85WUal6tHr5lcHP021vbHFdWG-RAeJrRv-dxBw0=.914dc93d-bea2-40f0-b853-b5b8c8009c41@github.com>

On Thu, 11 Apr 2024 22:54:16 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiEnvThreadState.cpp line 367:
>> 
>>> 365:       GetCurrentLocationClosure op;
>>> 366:       JvmtiHandshake::execute(&op, &tlh, thread, thread_h);
>>> 367: 
>> 
>> Seems we are missing a JvmtiVTMSTransitionDisabler.
>
> Good question, thanks.
> The `JvmtiVTMSTransitionDisabler` is supposed to be installed in the caller's context if needed.
> However, it is not easy to make sure it is always the case.
> At least, I see a couple of contexts when the `JvmtiVTMSTransitionDisabler` is not being installed.
> But it is not clear if it is really needed there. Let me do some extra analysis there.

Okay.  The class `GetCurrentLocationClosure` is used by the `reset_current_location` only. It is called for the SINGLE_STEP and REAKPOINT event types as the following assert is placed at the function start:

void JvmtiEnvThreadState::reset_current_location(jvmtiEvent event_type, bool enabled) {
  assert(event_type == JVMTI_EVENT_SINGLE_STEP || event_type == JVMTI_EVENT_BREAKPOINT,
         "must be single-step or breakpoint event");
 . . .

Also, this is the only two places where this function is called:

JvmtiEventControllerPrivate::recompute_env_thread_enabled(JvmtiEnvThreadState* ets, JvmtiThreadState* state) {
    . . .
    if (changed & SINGLE_STEP_BIT) {
      ets->reset_current_location(JVMTI_EVENT_SINGLE_STEP, (now_enabled & SINGLE_STEP_BIT) != 0);
    }
    if (changed & BREAKPOINT_BIT) {
      ets->reset_current_location(JVMTI_EVENT_BREAKPOINT,  (now_enabled & BREAKPOINT_BIT) != 0);
    }

The `reset_current_location` is called called in the context of the `SetEventNotificationMode` where a JvmtiVTMSTransitionDisabler is present.

Theoretically, it can be also triggered by the `SetEventCallbacks` (if callbacks are for SINGLE_STEP or REAKPOINT event type). But it also has a J`vmtiVTMSTransitionDisabler` in place:

JvmtiEnv::SetEventCallbacks(const jvmtiEventCallbacks* callbacks, jint size_of_callbacks) {
  JvmtiVTMSTransitionDisabler disabler;
  JvmtiEventController::set_event_callbacks(this, callbacks, size_of_callbacks);
  return JVMTI_ERROR_NONE;
} /* end SetEventCallbacks */

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18630#discussion_r1561903953

From amenkov at openjdk.org  Fri Apr 12 02:21:55 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 12 Apr 2024 02:21:55 GMT
Subject: RFR: 8322043: HeapDumper should use parallel dump by default
Message-ID: <m5p4qFndNtWAo_wwbdHKSJqG2XIcxwn_3tcJAYXAwgA=.dd4128e5-9688-45da-919e-683f4f6c6a10@github.com>

The fix makes VM heap dumping parallel by default.
`jcmd GC.heap_dump` and `jmap -dump` had parallel dumping by default, the fix affects `HotSpotDiagnosticMXBean.dumpHeap()`, `-XX:+HeapDumpBeforeFullGC`, `-XX:+HeapDumpAfterFullGC` and `-XX:+HeapDumpOnOutOfMemoryError`.

Testing:
  - manually tested different heap dump scenarios with `-Xlog:heapdump`;
  - tier1,tier2,hs-tier5-svc;
  - all reg.tests that use heap dump.

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

Commit messages:
 - fix

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

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

From stuefe at openjdk.org  Fri Apr 12 06:09:40 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 12 Apr 2024 06:09:40 GMT
Subject: RFR: 8322043: HeapDumper should use parallel dump by default
In-Reply-To: <m5p4qFndNtWAo_wwbdHKSJqG2XIcxwn_3tcJAYXAwgA=.dd4128e5-9688-45da-919e-683f4f6c6a10@github.com>
References: <m5p4qFndNtWAo_wwbdHKSJqG2XIcxwn_3tcJAYXAwgA=.dd4128e5-9688-45da-919e-683f4f6c6a10@github.com>
Message-ID: <T9dxQMWhzmAq8o6nUBB6_NZ8z7ZQG2oHvhwCTlEVf8M=.ed03bda0-f75d-46a7-b898-0e517cbd1ec3@github.com>

On Fri, 12 Apr 2024 02:17:34 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix makes VM heap dumping parallel by default.
> `jcmd GC.heap_dump` and `jmap -dump` had parallel dumping by default, the fix affects `HotSpotDiagnosticMXBean.dumpHeap()`, `-XX:+HeapDumpBeforeFullGC`, `-XX:+HeapDumpAfterFullGC` and `-XX:+HeapDumpOnOutOfMemoryError`.
> 
> Testing:
>   - manually tested different heap dump scenarios with `-Xlog:heapdump`;
>   - tier1,tier2,hs-tier5-svc;
>   - all reg.tests that use heap dump.

I am curious: what is the memory overhead for parallel mode, and (I am not familiar with the logic) how many threads are involved? Is the number of thread bounded?

I ask because, especially for the OnOOM handling, we may already be at a limit memory-wise. Starting to swap will probably be worse than running single-threaded.

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

PR Comment: https://git.openjdk.org/jdk/pull/18748#issuecomment-2051046673

From sspitsyn at openjdk.org  Fri Apr 12 12:00:55 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 12 Apr 2024 12:00:55 GMT
Subject: RFR: 8329674: JvmtiEnvThreadState::reset_current_location function
 should use JvmtiHandshake [v3]
In-Reply-To: <uRzHmRzrIpmqOZsolHvTzUW35Gy3m8EQe7rNJjizoOY=.fbac2bc8-acfe-4520-957c-83d7450ff8ce@github.com>
References: <uRzHmRzrIpmqOZsolHvTzUW35Gy3m8EQe7rNJjizoOY=.fbac2bc8-acfe-4520-957c-83d7450ff8ce@github.com>
Message-ID: <ltMFazItiWRpRDW1Deyg4aigqsSxoCy54VtAIJP6X0Q=.0d75f96b-5d0c-4f10-a425-2b5120127353@github.com>

> The internal JVM TI JvmtiHandshake and JvmtiUnitedHandshakeClosure classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor the JVM TI internal functions JvmtiEnvThreadState::reset_current_location on the base of JvmtiHandshake and JvmtiUnitedHandshakeClosure classes.
> 
> Testing:
>  - Ran mach5 tiers 1-6

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

  review: remove unneded check for is_vthread_alive; do not call do_thread from do_vthread

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18630/files
  - new: https://git.openjdk.org/jdk/pull/18630/files/39717f37..86775376

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

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

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

From snazarki at openjdk.org  Fri Apr 12 14:44:52 2024
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Fri, 12 Apr 2024 14:44:52 GMT
Subject: RFR: 8330171: Lazy W^X swtich implementation
Message-ID: <9eymaXovxUNFdkAkzojFQP5trwl_yyY0jE2GzcMEjR4=.02ee2ef9-c476-4c7c-9e4a-e021425c38bc@github.com>

An alternative for preemptively switching the W^X thread mode on macOS with an AArch64 CPU. This implementation triggers the switch in response to the SIGBUS signal if the *si_addr* belongs to the CodeCache area. With this approach, it is now feasible to eliminate all WX guards and avoid potentially costly operations. However, no significant improvement or degradation in performance has been observed.  Additionally, considering the issue with AsyncGetCallTrace, the patched JVM has been successfully operated with [asgct_bottom](https://github.com/parttimenerd/asgct_bottom) and [async-profiler](https://github.com/async-profiler/async-profiler). 

Additional testing:
- [x] MacOS AArch64 server fastdebug *gtets*
- [ ] MacOS AArch64 server fastdebug *jtreg:hotspot:tier4*
- [ ] Benchmarking

@apangin and @parttimenerd could you please check the patch on your scenarios??

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

Commit messages:
 - Fix non-macos builds
 - Revert "8304725: AsyncGetCallTrace can cause SIGBUS on M1"
 - Remove ThreadWXEnable guard
 - Lazy W^X state switch

Changes: https://git.openjdk.org/jdk/pull/18762/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18762&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330171
  Stats: 325 lines in 46 files changed: 17 ins; 305 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18762.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18762/head:pull/18762

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

From vkempik at openjdk.org  Fri Apr 12 14:53:44 2024
From: vkempik at openjdk.org (Vladimir Kempik)
Date: Fri, 12 Apr 2024 14:53:44 GMT
Subject: RFR: 8330171: Lazy W^X swtich implementation
In-Reply-To: <9eymaXovxUNFdkAkzojFQP5trwl_yyY0jE2GzcMEjR4=.02ee2ef9-c476-4c7c-9e4a-e021425c38bc@github.com>
References: <9eymaXovxUNFdkAkzojFQP5trwl_yyY0jE2GzcMEjR4=.02ee2ef9-c476-4c7c-9e4a-e021425c38bc@github.com>
Message-ID: <eDj_EGy4fShd2Q4spfYunpQjWHCwYBZUEEiVk7mo9QE=.4a721375-2f5f-4450-b943-f7061208d7a9@github.com>

On Fri, 12 Apr 2024 14:40:05 GMT, Sergey Nazarkin <snazarki at openjdk.org> wrote:

> An alternative for preemptively switching the W^X thread mode on macOS with an AArch64 CPU. This implementation triggers the switch in response to the SIGBUS signal if the *si_addr* belongs to the CodeCache area. With this approach, it is now feasible to eliminate all WX guards and avoid potentially costly operations. However, no significant improvement or degradation in performance has been observed.  Additionally, considering the issue with AsyncGetCallTrace, the patched JVM has been successfully operated with [asgct_bottom](https://github.com/parttimenerd/asgct_bottom) and [async-profiler](https://github.com/async-profiler/async-profiler). 
> 
> Additional testing:
> - [x] MacOS AArch64 server fastdebug *gtets*
> - [ ] MacOS AArch64 server fastdebug *jtreg:hotspot:tier4*
> - [ ] Benchmarking
> 
> @apangin and @parttimenerd could you please check the patch on your scenarios??

Hello Sergey.
W^X mode was initially forced by Apple to prevent writing to executable memory, as a security feature.
This change just eliminates this security feature at all, doesn't it ?
Basically: "want to write to Executable memory ? ok, here you go"

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

PR Comment: https://git.openjdk.org/jdk/pull/18762#issuecomment-2051910824

From aph at openjdk.org  Fri Apr 12 15:28:43 2024
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 12 Apr 2024 15:28:43 GMT
Subject: RFR: 8330171: Lazy W^X switch implementation
In-Reply-To: <eDj_EGy4fShd2Q4spfYunpQjWHCwYBZUEEiVk7mo9QE=.4a721375-2f5f-4450-b943-f7061208d7a9@github.com>
References: <9eymaXovxUNFdkAkzojFQP5trwl_yyY0jE2GzcMEjR4=.02ee2ef9-c476-4c7c-9e4a-e021425c38bc@github.com>
 <eDj_EGy4fShd2Q4spfYunpQjWHCwYBZUEEiVk7mo9QE=.4a721375-2f5f-4450-b943-f7061208d7a9@github.com>
Message-ID: <88Jsd_RmZ8QTcODe6MsTx2j54J8Dk6dJX-ZUpVIdxVs=.abd71be6-dba9-4851-9f93-009858d0c175@github.com>

On Fri, 12 Apr 2024 14:50:46 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

> Hello Sergey. W^X mode was initially forced by Apple to prevent writing to executable memory, as a security feature. This change just eliminates this security feature at all, doesn't it ? Basically: "want to write to Executable memory ? ok, here you go"

Yes @VladimirKempik, you are right. No, we should not do this.

Instead, when we enter the VM we could track the current state of W^X and whenever we enter a block that needs to write into code space we would set W if needed. When we leave the VM or when we call back into Java we would set X, if needed. The cost of doing this would be small, but we'd have to find all the blocks that need to write into code space. This might be more effort than we want to make, though.

So where would be need to make the transitions to W? At a guess, whenever we start assembling something, and in all of the methods in nativeInst_aarch64.?pp, and in class Patcher. And to X, in the call stub and a few other places.

That would minimize the transitions exactly to the set of places we actually need.

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

PR Comment: https://git.openjdk.org/jdk/pull/18762#issuecomment-2051977752

From vkempik at openjdk.org  Fri Apr 12 15:32:41 2024
From: vkempik at openjdk.org (Vladimir Kempik)
Date: Fri, 12 Apr 2024 15:32:41 GMT
Subject: RFR: 8330171: Lazy W^X switch implementation
In-Reply-To: <9eymaXovxUNFdkAkzojFQP5trwl_yyY0jE2GzcMEjR4=.02ee2ef9-c476-4c7c-9e4a-e021425c38bc@github.com>
References: <9eymaXovxUNFdkAkzojFQP5trwl_yyY0jE2GzcMEjR4=.02ee2ef9-c476-4c7c-9e4a-e021425c38bc@github.com>
Message-ID: <WSMsn6iefWdLHx7hsN6_50_Plkrjyi59W7BRVsblyDU=.9540d841-6feb-41c5-afc7-ef48527cce46@github.com>

On Fri, 12 Apr 2024 14:40:05 GMT, Sergey Nazarkin <snazarki at openjdk.org> wrote:

> An alternative for preemptively switching the W^X thread mode on macOS with an AArch64 CPU. This implementation triggers the switch in response to the SIGBUS signal if the *si_addr* belongs to the CodeCache area. With this approach, it is now feasible to eliminate all WX guards and avoid potentially costly operations. However, no significant improvement or degradation in performance has been observed.  Additionally, considering the issue with AsyncGetCallTrace, the patched JVM has been successfully operated with [asgct_bottom](https://github.com/parttimenerd/asgct_bottom) and [async-profiler](https://github.com/async-profiler/async-profiler). 
> 
> Additional testing:
> - [x] MacOS AArch64 server fastdebug *gtets*
> - [ ] MacOS AArch64 server fastdebug *jtreg:hotspot:tier4*
> - [ ] Benchmarking
> 
> @apangin and @parttimenerd could you please check the patch on your scenarios??

This can be left as an addition to existing mechanism. Disabled by default and can be enabled with a special (DEVELOP) option. So this can't be enabled on production builds, but can be useful to debug w^x issues on debug builds

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

PR Comment: https://git.openjdk.org/jdk/pull/18762#issuecomment-2051984322

From larry.cable at oracle.com  Fri Apr 12 15:32:48 2024
From: larry.cable at oracle.com (Laurence Cable)
Date: Fri, 12 Apr 2024 08:32:48 -0700
Subject: RFO: a tool to analyze HotSpot fatal error logs
In-Reply-To: <CAG0Tb0iiDxhLuG1Bkg=8xusAUyoX9ZyKt64rnP22Sau9LNvWJw@mail.gmail.com>
References: <CAG0Tb0iiDxhLuG1Bkg=8xusAUyoX9ZyKt64rnP22Sau9LNvWJw@mail.gmail.com>
Message-ID: <76ed1a5d-ec36-4e2c-a31a-af4c80b592a1@oracle.com>

Hi Maxim, a great idea, the JDK serviceability team here at Oracle would 
like to assist you in any way we can.

I think also we should (in the future) consider the format of the error 
file and associated jcmd and perhaps render the content
in a format that is better suited to programmatic parsing even a 
jq-esque formatter that took the human-readable format and
re-formatted would be useful (IMO)

Rgds

- Larry Cable


On 4/11/24 7:05 AM, Maxim Kartashev wrote:
> Hello,
>
> I am writing to inquire about the potential interest of the people 
> involved in inspecting HotSpot crashes in a tool aimed at facilitating 
> that inspection.
>
> We at JetBrains have developed an internal plugin that helps both with 
> filtering through dozens of reports quickly in order to find a pattern 
> and for diving deep into a particular crash. In addition to the 
> "standard" features such as syntax highlighting, folding, and 
> structural navigation, it will
> * highlight potential problems such as overloaded CPU, low physical 
> memory, the presence of OOME in the recent exceptions, LD_LIBRARY_PATH 
> being set, etc,
> * generate an "executive summary" for a high-level overview, for 
> example, by front-line support,
> * pop up a tooltip for any recognized address describing its origin 
> (for example, if it belongs to some thread's stack, the Java heap, a 
> register, or a memory-mapped region),
> * provide the ability to highlight all addresses "near" the selected 
> address, including registers, threads, and memory-mapped regions.
>
> If there is sufficient interest in creating a public and/or 
> open-source variant of this internal plugin, I will pitch the idea to 
> my employer. It shouldn't be too much work to create a public version.
>
> Kind regards,
> Maxim.
>
> References:
> * https://docs.oracle.com/javase/10/troubleshoot/fatal-error-log.htm
>


From pchilanomate at openjdk.org  Fri Apr 12 16:37:42 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 12 Apr 2024 16:37:42 GMT
Subject: RFR: 8329674: JvmtiEnvThreadState::reset_current_location function
 should use JvmtiHandshake [v3]
In-Reply-To: <ltMFazItiWRpRDW1Deyg4aigqsSxoCy54VtAIJP6X0Q=.0d75f96b-5d0c-4f10-a425-2b5120127353@github.com>
References: <uRzHmRzrIpmqOZsolHvTzUW35Gy3m8EQe7rNJjizoOY=.fbac2bc8-acfe-4520-957c-83d7450ff8ce@github.com>
 <ltMFazItiWRpRDW1Deyg4aigqsSxoCy54VtAIJP6X0Q=.0d75f96b-5d0c-4f10-a425-2b5120127353@github.com>
Message-ID: <ZVyFRJTk7e13isRZCe_OxDVTey8ASKm4khV4jI79Ri0=.e791cdec-07ab-47a0-85de-3dcbe2abe9d7@github.com>

On Fri, 12 Apr 2024 12:00:55 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The internal JVM TI JvmtiHandshake and JvmtiUnitedHandshakeClosure classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor the JVM TI internal functions JvmtiEnvThreadState::reset_current_location on the base of JvmtiHandshake and JvmtiUnitedHandshakeClosure classes.
>> 
>> Testing:
>>  - Ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: remove unneded check for is_vthread_alive; do not call do_thread from do_vthread

Thanks Serguei, looks good to me.

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

Marked as reviewed by pchilanomate (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18630#pullrequestreview-1997892115

From pchilanomate at openjdk.org  Fri Apr 12 16:37:42 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 12 Apr 2024 16:37:42 GMT
Subject: RFR: 8329674: JvmtiEnvThreadState::reset_current_location function
 should use JvmtiHandshake [v2]
In-Reply-To: <6hM-85WUal6tHr5lcHP021vbHFdWG-RAeJrRv-dxBw0=.914dc93d-bea2-40f0-b853-b5b8c8009c41@github.com>
References: <uRzHmRzrIpmqOZsolHvTzUW35Gy3m8EQe7rNJjizoOY=.fbac2bc8-acfe-4520-957c-83d7450ff8ce@github.com>
 <zIvIwWeNVfitoFQhWAtx9CWwGQD-veZ60BgwXGAKcAs=.90406a43-321c-43f5-b739-c58e04d39ad7@github.com>
 <10EU-jvOhZaur5uqCtnBJVodhqV8MKLzfI7IGBfo0cg=.348e71d1-0394-41fe-b511-3f3d7a35713c@github.com>
 <I3-FWexMuiNfgYZCUpB70ADoSbe30vqPoyTW_XaK3PI=.8f8649dc-6600-47da-a120-4be552b5eb87@github.com>
 <6hM-85WUal6tHr5lcHP021vbHFdWG-RAeJrRv-dxBw0=.914dc93d-bea2-40f0-b853-b5b8c8009c41@github.com>
Message-ID: <ieZyK5_3BwBFFHaUxFV-dST6-LyBc9Nh3OrTorHjXoE=.a7107818-95de-4ce9-a05b-b0f81290e228@github.com>

On Fri, 12 Apr 2024 01:22:04 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Good question, thanks.
>> The `JvmtiVTMSTransitionDisabler` is supposed to be installed in the caller's context if needed.
>> However, it is not easy to make sure it is always the case.
>> At least, I see a couple of contexts when the `JvmtiVTMSTransitionDisabler` is not being installed.
>> But it is not clear if it is really needed there. Let me do some extra analysis there.
>
> Okay.  The class `GetCurrentLocationClosure` is used by the `reset_current_location` only. It is called for the SINGLE_STEP and REAKPOINT event types as the following assert is placed at the function start:
> 
> void JvmtiEnvThreadState::reset_current_location(jvmtiEvent event_type, bool enabled) {
>   assert(event_type == JVMTI_EVENT_SINGLE_STEP || event_type == JVMTI_EVENT_BREAKPOINT,
>          "must be single-step or breakpoint event");
>  . . .
> 
> Also, this is the only two places where this function is called:
> 
> JvmtiEventControllerPrivate::recompute_env_thread_enabled(JvmtiEnvThreadState* ets, JvmtiThreadState* state) {
>     . . .
>     if (changed & SINGLE_STEP_BIT) {
>       ets->reset_current_location(JVMTI_EVENT_SINGLE_STEP, (now_enabled & SINGLE_STEP_BIT) != 0);
>     }
>     if (changed & BREAKPOINT_BIT) {
>       ets->reset_current_location(JVMTI_EVENT_BREAKPOINT,  (now_enabled & BREAKPOINT_BIT) != 0);
>     }
> 
> The `reset_current_location` is called called in the context of the `SetEventNotificationMode` where a JvmtiVTMSTransitionDisabler is present.
> 
> Theoretically, it can be also triggered by the `SetEventCallbacks` (if callbacks are for SINGLE_STEP or REAKPOINT event type). But it also has a J`vmtiVTMSTransitionDisabler` in place:
> 
> JvmtiEnv::SetEventCallbacks(const jvmtiEventCallbacks* callbacks, jint size_of_callbacks) {
>   JvmtiVTMSTransitionDisabler disabler;
>   JvmtiEventController::set_event_callbacks(this, callbacks, size_of_callbacks);
>   return JVMTI_ERROR_NONE;
> } /* end SetEventCallbacks */

Thanks for the investigation! Maybe we should have an assert that current->is_VTMS_transition_disabler() here or even in the JvmtiHandshake::execute() that expects we have one in scope? I see that we have some conditions where JvmtiVTMSTransitionDisabler is a no-op though so we would have to include does as well. Or maybe set the boolean even when it is a no-op.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18630#discussion_r1562813538

From sspitsyn at openjdk.org  Fri Apr 12 17:07:43 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 12 Apr 2024 17:07:43 GMT
Subject: RFR: 8329674: JvmtiEnvThreadState::reset_current_location function
 should use JvmtiHandshake [v3]
In-Reply-To: <ltMFazItiWRpRDW1Deyg4aigqsSxoCy54VtAIJP6X0Q=.0d75f96b-5d0c-4f10-a425-2b5120127353@github.com>
References: <uRzHmRzrIpmqOZsolHvTzUW35Gy3m8EQe7rNJjizoOY=.fbac2bc8-acfe-4520-957c-83d7450ff8ce@github.com>
 <ltMFazItiWRpRDW1Deyg4aigqsSxoCy54VtAIJP6X0Q=.0d75f96b-5d0c-4f10-a425-2b5120127353@github.com>
Message-ID: <GJwzOmyBMiD9BGKu9Hfq9BEyAkE6OG3UL_RZvwKZyUI=.7cd0564a-12fd-4e65-872e-a83bd0326be9@github.com>

On Fri, 12 Apr 2024 12:00:55 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The internal JVM TI JvmtiHandshake and JvmtiUnitedHandshakeClosure classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor the JVM TI internal functions JvmtiEnvThreadState::reset_current_location on the base of JvmtiHandshake and JvmtiUnitedHandshakeClosure classes.
>> 
>> Testing:
>>  - Ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: remove unneded check for is_vthread_alive; do not call do_thread from do_vthread

> Thanks for the investigation! Maybe we should have an assert that current->is_VTMS_transition_disabler() here or even in the JvmtiHandshake::execute() that expects we have one in scope? I see that we have some conditions where JvmtiVTMSTransitionDisabler is a no-op though so we would have to include does as well. Or maybe set the boolean even when it is a no-op.

I'm thinking about the same. It should be relatively easy to implement this check.

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

PR Comment: https://git.openjdk.org/jdk/pull/18630#issuecomment-2052144005

From snazarki at openjdk.org  Fri Apr 12 17:18:41 2024
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Fri, 12 Apr 2024 17:18:41 GMT
Subject: RFR: 8330171: Lazy W^X switch implementation
In-Reply-To: <88Jsd_RmZ8QTcODe6MsTx2j54J8Dk6dJX-ZUpVIdxVs=.abd71be6-dba9-4851-9f93-009858d0c175@github.com>
References: <9eymaXovxUNFdkAkzojFQP5trwl_yyY0jE2GzcMEjR4=.02ee2ef9-c476-4c7c-9e4a-e021425c38bc@github.com>
 <eDj_EGy4fShd2Q4spfYunpQjWHCwYBZUEEiVk7mo9QE=.4a721375-2f5f-4450-b943-f7061208d7a9@github.com>
 <88Jsd_RmZ8QTcODe6MsTx2j54J8Dk6dJX-ZUpVIdxVs=.abd71be6-dba9-4851-9f93-009858d0c175@github.com>
Message-ID: <MHy1h0_wjYYtDV61FSSch_11MEEqc3Z-FmktjJP76gc=.dcb04a48-08e2-40a4-a662-33a9d151006d@github.com>

On Fri, 12 Apr 2024 15:26:03 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Hello Sergey.
>> W^X mode was initially forced by Apple to prevent writing to executable memory, as a security feature.
>> This change just eliminates this security feature at all, doesn't it ?
>> Basically: "want to write to Executable memory ? ok, here you go"
>
>> Hello Sergey. W^X mode was initially forced by Apple to prevent writing to executable memory, as a security feature. This change just eliminates this security feature at all, doesn't it ? Basically: "want to write to Executable memory ? ok, here you go"
> 
> Yes @VladimirKempik, you are right. No, we should not do this.
> 
> Instead, when we enter the VM we could track the current state of W^X and whenever we enter a block that needs to write into code space we would set W if needed. When we leave the VM or when we call back into Java we would set X, if needed. The cost of doing this would be small, but we'd have to find all the blocks that need to write into code space. This might be more effort than we want to make, though.
> 
> So where would be need to make the transitions to W? At a guess, whenever we start assembling something, and in all of the methods in nativeInst_aarch64.?pp, and in class Patcher. And to X, in the call stub and a few other places.
> 
> That would minimize the transitions exactly to the set of places we actually need.

Thanks @theRealAph, @VladimirKempik
> Instead, when we enter the VM we could track the current state of W^X and whenever we enter a block that needs to write into code space we would set W if needed. When we leave the VM or when we call back into Java we would set X, if needed. The cost of doing this would be small, but we'd have to find all the blocks that need to write into code space. This might be more effort than we want to make, though.

?It is the way in which it is implemented in the current code.  Unfortunately, it is hardly maintainable solution that suffers from issues like [1-5].   

As I understand it, your concern is that the implementation doesn't prevent rogue from writing to the code cache with some some unsafe api? 

1. https://bugs.openjdk.org/browse/JDK-8302736
2. https://bugs.openjdk.org/browse/JDK-8327990
3. https://bugs.openjdk.org/browse/JDK-8327036
4. https://bugs.openjdk.org/browse/JDK-8304725
5. https://bugs.openjdk.org/browse/JDK-8307549

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

PR Comment: https://git.openjdk.org/jdk/pull/18762#issuecomment-2052164890

From jjg at openjdk.org  Fri Apr 12 17:24:43 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 12 Apr 2024 17:24:43 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v2]
In-Reply-To: <CJk_cgw_oK69SgmEsA7fC7wupoZ6Uc_MJ_vAEFUhMlc=.3b61473c-97e6-4a9a-b19b-e387ab9eb5ab@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
 <CJk_cgw_oK69SgmEsA7fC7wupoZ6Uc_MJ_vAEFUhMlc=.3b61473c-97e6-4a9a-b19b-e387ab9eb5ab@github.com>
Message-ID: <yoXk0XJ1mo_6lFPzenTjynOJmM2R8GNROFOTwN4p00g=.dcedceac-6d2a-4b1f-99ee-57d060b8a69b@github.com>

On Wed, 3 Apr 2024 10:01:37 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adjust call for `saveDanglingDocComments` for enum members
>
> The build changes look okay. 
> 
> Do you have any plan of going through all the Java modules and fixing the issues, or opening JBS issues to have them fixed? Or will these lint warnings remain disabled for the foreseeable future?

@magicus 
> The build changes look okay.
> 
> Do you have any plan of going through all the Java modules and fixing the issues, or opening JBS issues to have them fixed? Or will these lint warnings remain disabled for the foreseeable future?

The plan is to create an umbrella bug to clean up the individual modules. There is interest to clean up `java.base`, to keep that one free of any warnings, and I can see that the lang tools modules will get cleaner up as well. It will be up to other component teams to decide if and when to clean up other parts of the system.  Once this work has been integrated, it is relatively easy to enable the warnings for a module and to fix the ensuing issues. Since any changes "only" involve comments, it should be reasonably easy to fix them, unlike some pervasive other warnings, like `this-escape`.

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

PR Comment: https://git.openjdk.org/jdk/pull/18527#issuecomment-2052174696

From sspitsyn at openjdk.org  Fri Apr 12 17:49:41 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 12 Apr 2024 17:49:41 GMT
Subject: RFR: 8329674: JvmtiEnvThreadState::reset_current_location function
 should use JvmtiHandshake [v3]
In-Reply-To: <ltMFazItiWRpRDW1Deyg4aigqsSxoCy54VtAIJP6X0Q=.0d75f96b-5d0c-4f10-a425-2b5120127353@github.com>
References: <uRzHmRzrIpmqOZsolHvTzUW35Gy3m8EQe7rNJjizoOY=.fbac2bc8-acfe-4520-957c-83d7450ff8ce@github.com>
 <ltMFazItiWRpRDW1Deyg4aigqsSxoCy54VtAIJP6X0Q=.0d75f96b-5d0c-4f10-a425-2b5120127353@github.com>
Message-ID: <0hvY7WAjlccqf083w6WmAG4IU8giI0kSQJmRGvg7QjY=.70098480-43cf-45cf-9eee-a4a33776edeb@github.com>

On Fri, 12 Apr 2024 12:00:55 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The internal JVM TI JvmtiHandshake and JvmtiUnitedHandshakeClosure classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor the JVM TI internal functions JvmtiEnvThreadState::reset_current_location on the base of JvmtiHandshake and JvmtiUnitedHandshakeClosure classes.
>> 
>> Testing:
>>  - Ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: remove unneded check for is_vthread_alive; do not call do_thread from do_vthread

Thank you for review, Patricio!

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

PR Comment: https://git.openjdk.org/jdk/pull/18630#issuecomment-2052207437

From cjplummer at openjdk.org  Fri Apr 12 18:08:42 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 12 Apr 2024 18:08:42 GMT
Subject: RFR: 8240343: JDI stopListening/stoplis001
 "FAILED: listening is successfully stopped without starting listening" [v2]
In-Reply-To: <XjGts1DnTzhfuPq7RbkaindOZqJyllrHqAvXkV2vnXc=.1a975d46-9069-405f-a8b0-3f87dcce6390@github.com>
References: <iGvL2MQ9wvrjf5QKf9zd0LEF-KAnUZrUPXM0k3bQluE=.6cd6c780-75f9-412a-aa39-10e1b00a90a3@github.com>
 <XjGts1DnTzhfuPq7RbkaindOZqJyllrHqAvXkV2vnXc=.1a975d46-9069-405f-a8b0-3f87dcce6390@github.com>
Message-ID: <pAMP6NH4hQt7tTvwTBmD73YUkWXHhUrUM4WnGaGbZGQ=.88c539ed-1a59-46d8-9a7f-3218def492a3@github.com>

On Wed, 10 Apr 2024 17:36:32 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The test starts listening on dynamic port and calls stopListening with incorrect (cArgs1) and correct (cArgs2) argument maps.
>> Incorrect map is created by finding "free" port (`(new ServerSocket(0)).getLocalPort()`)
>> The test fails if the same port is selected later when the listening starts.
>> To avoid this free port should be picked after listening on dynamic port started.
>> 
>> Additionally removed unnecessary `exclusiveAccess.dirs=.` test property and incorrect comment in the description.
>> The test uses `SocketListen` connectors, the coment is about `SharedMemoryListen` connector.
>> 
>> Testing: run the test on all Oracle-supported platforms 100 times
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/hotspot/jtreg/vmTestbase/nsk/jdi/ListeningConnector/stopListening/stoplis001.java
>   
>   Co-authored-by: Chris Plummer <chris.plummer at oracle.com>

You might want to consider adding the following diff. It will help in case this issue (or similar) reproduces again:


--- a/test/hotspot/jtreg/vmTestbase/nsk/jdi/ListeningConnector/stopListening/stoplis001.java
+++ b/test/hotspot/jtreg/vmTestbase/nsk/jdi/ListeningConnector/stopListening/stoplis001.java
@@ -92,6 +92,8 @@ private int runIt(String argv[], PrintStream out) {
         }
         else
             log.display("TEST: start listening the address " + addr);
+        log.display("cArgs1: " + cArgs1);
+        log.display("cArgs2: " + cArgs2);
 
 /* Check that an Exception is thrown if ListeningConnector.stopListening
  has been invoked with argument map different from the one given for



 TEST: start listening the address localhost:42473
cArgs1: {timeout=timeout=, port=port=45521, localAddress=localAddress=}
cArgs2: {timeout=timeout=, port=port=42473, localAddress=localAddress=}

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

PR Comment: https://git.openjdk.org/jdk/pull/18705#issuecomment-2052232161

From amenkov at openjdk.org  Fri Apr 12 18:53:44 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 12 Apr 2024 18:53:44 GMT
Subject: RFR: 8322043: HeapDumper should use parallel dump by default
In-Reply-To: <T9dxQMWhzmAq8o6nUBB6_NZ8z7ZQG2oHvhwCTlEVf8M=.ed03bda0-f75d-46a7-b898-0e517cbd1ec3@github.com>
References: <m5p4qFndNtWAo_wwbdHKSJqG2XIcxwn_3tcJAYXAwgA=.dd4128e5-9688-45da-919e-683f4f6c6a10@github.com>
 <T9dxQMWhzmAq8o6nUBB6_NZ8z7ZQG2oHvhwCTlEVf8M=.ed03bda0-f75d-46a7-b898-0e517cbd1ec3@github.com>
Message-ID: <C8yTf4InaiP25TPwnR6CkBUucOm1XxxcS8Mcad7mWdU=.4a8c58b9-aed9-4d7a-998d-68196707bea4@github.com>

On Fri, 12 Apr 2024 06:07:31 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I am curious: what is the memory overhead for parallel mode, and (I am not familiar with the logic) how many threads are involved? Is the number of thread bounded?
> 
> I ask because, especially for the OnOOM handling, we may already be at a limit memory-wise. Starting to swap will probably be worse than running single-threaded.

Good question.
It think it's several MB per each additional thread (1MB output buffer, DumperClassCacheTable - 1031 elements max, element size depends on class field numbers, if HeapDumpGzipLevel is set, some buffers for gzip compressors)
Number of threads by default is min of `os::initial_active_processor_count() * 3 / 8` and number of GC workers.

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

PR Comment: https://git.openjdk.org/jdk/pull/18748#issuecomment-2052312786

From jjg at openjdk.org  Fri Apr 12 21:04:06 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 12 Apr 2024 21:04:06 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v3]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <3Ynu_D2CcFh3usjCkWQVk7VFhTlxVzD4f2nVhvZrP50=.f1c29740-ff73-4a0c-a63b-3e00ece05bbf@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  call `saveDanglingDocComments` for local variable declarations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18527/files
  - new: https://git.openjdk.org/jdk/pull/18527/files/56d6dcac..3f745431

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

  Stats: 10 lines in 1 file changed: 5 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18527/head:pull/18527

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

From amenkov at openjdk.org  Fri Apr 12 21:08:54 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 12 Apr 2024 21:08:54 GMT
Subject: RFR: 8240343: JDI stopListening/stoplis001
 "FAILED: listening is successfully stopped without starting listening" [v3]
In-Reply-To: <iGvL2MQ9wvrjf5QKf9zd0LEF-KAnUZrUPXM0k3bQluE=.6cd6c780-75f9-412a-aa39-10e1b00a90a3@github.com>
References: <iGvL2MQ9wvrjf5QKf9zd0LEF-KAnUZrUPXM0k3bQluE=.6cd6c780-75f9-412a-aa39-10e1b00a90a3@github.com>
Message-ID: <zmUO1TcFjPI74HM63h8xn9i0f3lMobKGYXZqD4ybFBw=.9fcaa0f5-9278-437e-a101-ae3c7e6d343a@github.com>

> The test starts listening on dynamic port and calls stopListening with incorrect (cArgs1) and correct (cArgs2) argument maps.
> Incorrect map is created by finding "free" port (`(new ServerSocket(0)).getLocalPort()`)
> The test fails if the same port is selected later when the listening starts.
> To avoid this free port should be picked after listening on dynamic port started.
> 
> Additionally removed unnecessary `exclusiveAccess.dirs=.` test property and incorrect comment in the description.
> The test uses `SocketListen` connectors, the coment is about `SharedMemoryListen` connector.
> 
> Testing: run the test on all Oracle-supported platforms 100 times

Alex Menkov has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch 'stopListening' of github.com:alexmenkov/jdk into stopListening
 - arg map logging

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18705/files
  - new: https://git.openjdk.org/jdk/pull/18705/files/3b0d5540..a04363d6

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

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

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

From amenkov at openjdk.org  Fri Apr 12 21:18:42 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 12 Apr 2024 21:18:42 GMT
Subject: RFR: 8240343: JDI stopListening/stoplis001
 "FAILED: listening is successfully stopped without starting listening" [v2]
In-Reply-To: <pAMP6NH4hQt7tTvwTBmD73YUkWXHhUrUM4WnGaGbZGQ=.88c539ed-1a59-46d8-9a7f-3218def492a3@github.com>
References: <iGvL2MQ9wvrjf5QKf9zd0LEF-KAnUZrUPXM0k3bQluE=.6cd6c780-75f9-412a-aa39-10e1b00a90a3@github.com>
 <XjGts1DnTzhfuPq7RbkaindOZqJyllrHqAvXkV2vnXc=.1a975d46-9069-405f-a8b0-3f87dcce6390@github.com>
 <pAMP6NH4hQt7tTvwTBmD73YUkWXHhUrUM4WnGaGbZGQ=.88c539ed-1a59-46d8-9a7f-3218def492a3@github.com>
Message-ID: <Y9psGZOfDJjge3DuN5nUceG9zb8fCBth_Ycuswn0s8s=.869c1934-beaf-43c0-906d-ae4b919f66aa@github.com>

On Fri, 12 Apr 2024 18:05:59 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> You might want to consider adding the following diff. It will help in case this issue (or similar) reproduces again:
> 
makes sense. added.

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

PR Comment: https://git.openjdk.org/jdk/pull/18705#issuecomment-2052542650

From cjplummer at openjdk.org  Fri Apr 12 22:06:51 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 12 Apr 2024 22:06:51 GMT
Subject: RFR: 8240343: JDI stopListening/stoplis001
 "FAILED: listening is successfully stopped without starting listening" [v3]
In-Reply-To: <zmUO1TcFjPI74HM63h8xn9i0f3lMobKGYXZqD4ybFBw=.9fcaa0f5-9278-437e-a101-ae3c7e6d343a@github.com>
References: <iGvL2MQ9wvrjf5QKf9zd0LEF-KAnUZrUPXM0k3bQluE=.6cd6c780-75f9-412a-aa39-10e1b00a90a3@github.com>
 <zmUO1TcFjPI74HM63h8xn9i0f3lMobKGYXZqD4ybFBw=.9fcaa0f5-9278-437e-a101-ae3c7e6d343a@github.com>
Message-ID: <RW9OpZJ5EMDWJaXndcKVzctjlS_Odoev4m31xSGi-tI=.ed0de01f-cb86-4c2f-992e-57aca1d89d92@github.com>

On Fri, 12 Apr 2024 21:08:54 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The test starts listening on dynamic port and calls stopListening with incorrect (cArgs1) and correct (cArgs2) argument maps.
>> Incorrect map is created by finding "free" port (`(new ServerSocket(0)).getLocalPort()`)
>> The test fails if the same port is selected later when the listening starts.
>> To avoid this free port should be picked after listening on dynamic port started.
>> 
>> Additionally removed unnecessary `exclusiveAccess.dirs=.` test property and incorrect comment in the description.
>> The test uses `SocketListen` connectors, the coment is about `SharedMemoryListen` connector.
>> 
>> Testing: run the test on all Oracle-supported platforms 100 times
>
> Alex Menkov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'stopListening' of github.com:alexmenkov/jdk into stopListening
>  - arg map logging

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18705#pullrequestreview-1998507304

From amenkov at openjdk.org  Fri Apr 12 22:32:46 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 12 Apr 2024 22:32:46 GMT
Subject: Integrated: 8240343: JDI stopListening/stoplis001
 "FAILED: listening is successfully stopped without starting listening"
In-Reply-To: <iGvL2MQ9wvrjf5QKf9zd0LEF-KAnUZrUPXM0k3bQluE=.6cd6c780-75f9-412a-aa39-10e1b00a90a3@github.com>
References: <iGvL2MQ9wvrjf5QKf9zd0LEF-KAnUZrUPXM0k3bQluE=.6cd6c780-75f9-412a-aa39-10e1b00a90a3@github.com>
Message-ID: <bzJSSBrjQZNwWAacCX2FTmo_2Kda0aV1CM4jXpxap8U=.63d6f218-4d44-4617-80e9-eb8a59c46a23@github.com>

On Wed, 10 Apr 2024 00:28:01 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The test starts listening on dynamic port and calls stopListening with incorrect (cArgs1) and correct (cArgs2) argument maps.
> Incorrect map is created by finding "free" port (`(new ServerSocket(0)).getLocalPort()`)
> The test fails if the same port is selected later when the listening starts.
> To avoid this free port should be picked after listening on dynamic port started.
> 
> Additionally removed unnecessary `exclusiveAccess.dirs=.` test property and incorrect comment in the description.
> The test uses `SocketListen` connectors, the coment is about `SharedMemoryListen` connector.
> 
> Testing: run the test on all Oracle-supported platforms 100 times

This pull request has now been integrated.

Changeset: 28b20195
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/28b201955907e145f208d756b607ab545a83b2d3
Stats:     34 lines in 3 files changed: 6 ins; 28 del; 0 mod

8240343: JDI stopListening/stoplis001 "FAILED: listening is successfully stopped without starting listening"

Reviewed-by: cjplummer, sspitsyn

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

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

From kvn at openjdk.org  Fri Apr 12 22:48:01 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 12 Apr 2024 22:48:01 GMT
Subject: RFR: 8329433: Reduce nmethod header size
Message-ID: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>

This is part of changes which try to reduce size of `nmethod` and `codeblob` data vs code in CodeCache.
These changes reduced size of `nmethod` header from 288 to 240 bytes. From 304 to 256 in optimized VM:

Statistics for 1282 bytecoded nmethods for C2:
 total in heap = 5560352 (100%)
 header = 389728 (7.009053%)

vs

Statistics for 1298 bytecoded nmethods for C2:
 total in heap  = 5766040 (100%)
 header         = 332288 (5.762846%)


Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some fields were changed from `int` to `int16_t` with added corresponding asserts to make sure their values are fit into 16 bits.

I did additional cleanup after recent `CompiledMethod` removal.

Tested tier1-7,stress,xcomp and performance testing.

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

Commit messages:
 - 8329433: Reduce nmethod header size

Changes: https://git.openjdk.org/jdk/pull/18768/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18768&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329433
  Stats: 386 lines in 15 files changed: 92 ins; 115 del; 179 mod
  Patch: https://git.openjdk.org/jdk/pull/18768.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18768/head:pull/18768

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

From kvn at openjdk.org  Fri Apr 12 23:19:47 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 12 Apr 2024 23:19:47 GMT
Subject: RFR: 8329433: Reduce nmethod header size
In-Reply-To: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
Message-ID: <gtI-_C5UpycRp_qTs7XEe6opYAZMRt1iEXlUbRzMc0E=.1b180275-e49a-4f08-ac87-1a019c89d2f8@github.com>

On Fri, 12 Apr 2024 22:43:15 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> This is part of changes which try to reduce size of `nmethod` and `codeblob` data vs code in CodeCache.
> These changes reduced size of `nmethod` header from 288 to 240 bytes. From 304 to 256 in optimized VM:
> 
> Statistics for 1282 bytecoded nmethods for C2:
>  total in heap = 5560352 (100%)
>  header = 389728 (7.009053%)
> 
> vs
> 
> Statistics for 1298 bytecoded nmethods for C2:
>  total in heap  = 5766040 (100%)
>  header         = 332288 (5.762846%)
> 
> 
> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some fields were changed from `int` to `int16_t` with added corresponding asserts to make sure their values are fit into 16 bits.
> 
> I did additional cleanup after recent `CompiledMethod` removal.
> 
> Tested tier1-7,stress,xcomp and performance testing.

src/hotspot/share/code/codeBlob.cpp line 78:

> 76: #ifdef ASSERT
> 77: void CodeBlob::verify_parameters() {
> 78:   assert(is_aligned(_size,            oopSize), "unaligned size");

Asserts moved to only caller.

src/hotspot/share/code/codeBlob.cpp line 92:

> 90: CodeBlob::CodeBlob(const char* name, CodeBlobKind kind, int size, int header_size, int relocation_size,
> 91:                    int content_offset, int code_offset, int frame_complete_offset, int data_offset,
> 92:                    int frame_size, ImmutableOopMapSet* oop_maps, bool caller_must_gc_arguments) :

This was used only by `CompiledMethod` class.

src/hotspot/share/code/codeBlob.cpp line 129:

> 127: }
> 128: 
> 129: void CodeBlob::purge() {

Arguments are not used.

src/hotspot/share/code/codeBlob.hpp line 228:

> 226:   const ImmutableOopMap* oop_map_for_slot(int slot, address return_address) const;
> 227:   const ImmutableOopMap* oop_map_for_return_address(address return_address) const;
> 228:   virtual void preserve_callee_argument_oops(frame fr, const RegisterMap* reg_map, OopClosure* f) = 0;

This method is not empty only in `nmethod`. Converted to normal method there and added check` cb->is_nmethod()` in call sites.

src/hotspot/share/code/debugInfoRec.cpp line 251:

> 249:   void print() {
> 250:     tty->print_cr("Debug Data Chunks: %d, shared %d, non-SP's elided %d",
> 251:                   chunks_queried, chunks_shared, chunks_elided);

`chunks_reshared` is not used.

src/hotspot/share/code/dependencies.cpp line 391:

> 389:   address end = nm->dependencies_end();
> 390:   guarantee(end - beg >= (ptrdiff_t) size_in_bytes(), "bad sizing");
> 391:   (void)memcpy(beg, content_bytes(), size_in_bytes());

To avoid false error reported by `GCC` only during product VM build for `linux-x64`:

inlined from 'void Dependencies::copy_to(nmethod*)' at src/hotspot/share/code/dependencies.cpp:391:23:
src/hotspot/cpu/x86/copy_x86.hpp:110:18: error: writing 8 bytes into a region of size 0 [-Werror=stringop-overflow=]
   110 |   case 8:  to[7] = from[7];
       |            ~~~~~~^~~~~~~~~

src/hotspot/share/code/nmethod.cpp line 142:

> 140:   uint size_gt_32k;
> 141:   int size_max;
> 142: 

Diagnostic code leftover from my work on [#18554](https://github.com/openjdk/jdk/pull/18554)

src/hotspot/share/code/nmethod.cpp line 1486:

> 1484:     }
> 1485: #endif
> 1486:     dependencies->copy_to(this);

Missed to revert back this change.

src/hotspot/share/code/nmethod.hpp line 208:

> 206:   address  _osr_entry_point;       // entry point for on stack replacement
> 207:   uint16_t _entry_offset;          // entry point with class check
> 208:   uint16_t _verified_entry_offset; // entry point without class check

Changed direct entry pointers (8 bytes each in 64-bit VM) to offsets (2 bytes) to `code_begin()`.

src/hotspot/share/code/nmethod.hpp line 234:

> 232:   int      _scopes_data_offset;
> 233:   int      _handler_table_offset;
> 234:   int      _nul_chk_table_offset;

Changed data sections offsets base from `header_begin()` to `data_begin()`.
Note, `ScopesPcs` and `ScopesData` data could be > 64Kb.

src/hotspot/share/code/nmethod.hpp line 237:

> 235: #if INCLUDE_JVMCI
> 236:   int      _speculations_offset;
> 237:   int      _jvmci_data_offset;

"Wasted space" when Graal is not used. May be address in future changes.

src/hotspot/share/code/nmethod.hpp line 274:

> 272:   // used by jvmti to track if an event has been posted for this nmethod.
> 273:   bool _load_reported;
> 274: 

Converted to bit mask.

src/hotspot/share/code/nmethod.hpp line 724:

> 722:   ExceptionCache* exception_cache() const         { return _exception_cache; }
> 723:   ExceptionCache* exception_cache_acquire() const;
> 724:   void set_exception_cache(ExceptionCache *ec)    { _exception_cache = ec; }

Not used.

src/hotspot/share/code/nmethod.hpp line 800:

> 798: 
> 799:   // Deallocate this nmethod - called by the GC
> 800:   void purge(bool unregister_nmethod);

Only `unregister_nmethod` is used by code.

src/hotspot/share/memory/heap.hpp line 42:

> 40:   struct Header {
> 41:     uint32_t  _length;                           // the length in segments
> 42:     bool      _used;                             // Used bit

The `Header` size is aligned up 8 bytes. With `size_t length;` the aligned size will be 16 bytes.

`HeapBlock/Header` is used by CodeCache only which has 2Gb limit. The `length` counts number of segments which smallest size (`CodeCacheSegmentSize`) is 64 bytes.  32 bits is enough to cover it.

src/hotspot/share/runtime/frame.cpp line 979:

> 977:     if (reg_map->include_argument_oops() && _cb->is_nmethod()) {
> 978:       // Only nmethod preserves outgoing arguments at call.
> 979:       _cb->as_nmethod()->preserve_callee_argument_oops(*this, reg_map, f);

Only `nmethod` preserves arguments oops.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1563303217
PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1563302110
PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1563303989
PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1563307999
PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1563310748
PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1563311696
PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1563313116
PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1563334063
PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1563317344
PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1563320172
PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1563321008
PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1563321437
PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1563321900
PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1563322669
PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1563331968
PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1563332602

From stuefe at openjdk.org  Sat Apr 13 06:03:44 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 13 Apr 2024 06:03:44 GMT
Subject: RFR: 8322043: HeapDumper should use parallel dump by default
In-Reply-To: <C8yTf4InaiP25TPwnR6CkBUucOm1XxxcS8Mcad7mWdU=.4a8c58b9-aed9-4d7a-998d-68196707bea4@github.com>
References: <m5p4qFndNtWAo_wwbdHKSJqG2XIcxwn_3tcJAYXAwgA=.dd4128e5-9688-45da-919e-683f4f6c6a10@github.com>
 <T9dxQMWhzmAq8o6nUBB6_NZ8z7ZQG2oHvhwCTlEVf8M=.ed03bda0-f75d-46a7-b898-0e517cbd1ec3@github.com>
 <C8yTf4InaiP25TPwnR6CkBUucOm1XxxcS8Mcad7mWdU=.4a8c58b9-aed9-4d7a-998d-68196707bea4@github.com>
Message-ID: <TCMuaQ0Yoln7IT2D4FEZq5pDQUMQ59tecGX8oE18_FQ=.150f22f6-a42c-48f3-b351-04e34a8c401e@github.com>

On Fri, 12 Apr 2024 18:50:37 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> > I am curious: what is the memory overhead for parallel mode, and (I am not familiar with the logic) how many threads are involved? Is the number of thread bounded?
> > I ask because, especially for the OnOOM handling, we may already be at a limit memory-wise. Starting to swap will probably be worse than running single-threaded.
> 
> Good question. It think it's several MB per each additional thread (1MB output buffer, DumperClassCacheTable - 1031 elements max, element size depends on class field numbers, if HeapDumpGzipLevel is set, some buffers for gzip compressors) Number of threads by default is min of `os::initial_active_processor_count() * 3 / 8` and number of GC workers.

For the OOM case, I would probably make it somehow dependent on os::free_memory() then.

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

PR Comment: https://git.openjdk.org/jdk/pull/18748#issuecomment-2053517286

From sspitsyn at openjdk.org  Sat Apr 13 06:57:05 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 13 Apr 2024 06:57:05 GMT
Subject: RFR: 8329674: JvmtiEnvThreadState::reset_current_location function
 should use JvmtiHandshake [v4]
In-Reply-To: <uRzHmRzrIpmqOZsolHvTzUW35Gy3m8EQe7rNJjizoOY=.fbac2bc8-acfe-4520-957c-83d7450ff8ce@github.com>
References: <uRzHmRzrIpmqOZsolHvTzUW35Gy3m8EQe7rNJjizoOY=.fbac2bc8-acfe-4520-957c-83d7450ff8ce@github.com>
Message-ID: <udCHazv47WOEYWY_BFmrdB-Q3xIS0qiltoy0ek_f1n4=.d92a65f0-4160-4ab0-83c6-e2994a207a38@github.com>

> The internal JVM TI JvmtiHandshake and JvmtiUnitedHandshakeClosure classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor the JVM TI internal functions JvmtiEnvThreadState::reset_current_location on the base of JvmtiHandshake and JvmtiUnitedHandshakeClosure classes.
> 
> Testing:
>  - Ran mach5 tiers 1-6

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

  review: add an assert for missing JvmtiVTMSTransitionDisabler

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18630/files
  - new: https://git.openjdk.org/jdk/pull/18630/files/86775376..68687dca

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

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

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

From sspitsyn at openjdk.org  Sat Apr 13 09:24:45 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 13 Apr 2024 09:24:45 GMT
Subject: Integrated: 8329674: JvmtiEnvThreadState::reset_current_location
 function should use JvmtiHandshake
In-Reply-To: <uRzHmRzrIpmqOZsolHvTzUW35Gy3m8EQe7rNJjizoOY=.fbac2bc8-acfe-4520-957c-83d7450ff8ce@github.com>
References: <uRzHmRzrIpmqOZsolHvTzUW35Gy3m8EQe7rNJjizoOY=.fbac2bc8-acfe-4520-957c-83d7450ff8ce@github.com>
Message-ID: <qSGXpxYljftzPSBE-eUcn-N2YJ1dAasjmJhOB3KEmwQ=.4a8c3b00-7012-4400-a812-255d7c6d04aa@github.com>

On Thu, 4 Apr 2024 15:28:41 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The internal JVM TI JvmtiHandshake and JvmtiUnitedHandshakeClosure classes were introduced in the JDK 22 to unify/simplify the JVM TI functions supporting implementation of the virtual threads. This enhancement is to refactor the JVM TI internal functions JvmtiEnvThreadState::reset_current_location on the base of JvmtiHandshake and JvmtiUnitedHandshakeClosure classes.
> 
> Testing:
>  - Ran mach5 tiers 1-6

This pull request has now been integrated.

Changeset: c1c99a66
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c1c99a669bb7f9928086db6a4ecfc90c410ffbb0
Stats:     101 lines in 3 files changed: 28 ins; 67 del; 6 mod

8329674: JvmtiEnvThreadState::reset_current_location function should use JvmtiHandshake

Reviewed-by: lmesnik, pchilanomate

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

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

From stuefe at openjdk.org  Sat Apr 13 18:18:41 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 13 Apr 2024 18:18:41 GMT
Subject: RFR: 8330171: Lazy W^X switch implementation
In-Reply-To: <9eymaXovxUNFdkAkzojFQP5trwl_yyY0jE2GzcMEjR4=.02ee2ef9-c476-4c7c-9e4a-e021425c38bc@github.com>
References: <9eymaXovxUNFdkAkzojFQP5trwl_yyY0jE2GzcMEjR4=.02ee2ef9-c476-4c7c-9e4a-e021425c38bc@github.com>
Message-ID: <PQCCRRVbiMnuCRhJp6mNeIyPU1zFSP0UXpWQ5tq4Fuc=.14c30570-f138-4615-bae6-e6e861c6be4b@github.com>

On Fri, 12 Apr 2024 14:40:05 GMT, Sergey Nazarkin <snazarki at openjdk.org> wrote:

> An alternative for preemptively switching the W^X thread mode on macOS with an AArch64 CPU. This implementation triggers the switch in response to the SIGBUS signal if the *si_addr* belongs to the CodeCache area. With this approach, it is now feasible to eliminate all WX guards and avoid potentially costly operations. However, no significant improvement or degradation in performance has been observed.  Additionally, considering the issue with AsyncGetCallTrace, the patched JVM has been successfully operated with [asgct_bottom](https://github.com/parttimenerd/asgct_bottom) and [async-profiler](https://github.com/async-profiler/async-profiler). 
> 
> Additional testing:
> - [x] MacOS AArch64 server fastdebug *gtets*
> - [ ] MacOS AArch64 server fastdebug *jtreg:hotspot:tier4*
> - [ ] Benchmarking
> 
> @apangin and @parttimenerd could you please check the patch on your scenarios??

I have one question, and I'm sorry if it has been answered before. How expensive is changing the mode? Is it just a status variable in user-space pthread lib? Or does it need a system call? 

In other words, how fine granular can we get without incurring too high a cost?

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

PR Comment: https://git.openjdk.org/jdk/pull/18762#issuecomment-2053721713

From aph at openjdk.org  Sat Apr 13 19:09:46 2024
From: aph at openjdk.org (Andrew Haley)
Date: Sat, 13 Apr 2024 19:09:46 GMT
Subject: RFR: 8330171: Lazy W^X switch implementation
In-Reply-To: <PQCCRRVbiMnuCRhJp6mNeIyPU1zFSP0UXpWQ5tq4Fuc=.14c30570-f138-4615-bae6-e6e861c6be4b@github.com>
References: <9eymaXovxUNFdkAkzojFQP5trwl_yyY0jE2GzcMEjR4=.02ee2ef9-c476-4c7c-9e4a-e021425c38bc@github.com>
 <PQCCRRVbiMnuCRhJp6mNeIyPU1zFSP0UXpWQ5tq4Fuc=.14c30570-f138-4615-bae6-e6e861c6be4b@github.com>
Message-ID: <64tQxEFk-VGE424wdgtQgzEQnj9R5POxrLCKyGEpEGw=.7f40b04f-fdb8-4485-b530-1841384dbc8a@github.com>

On Sat, 13 Apr 2024 18:16:21 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I have one question, and I'm sorry if it has been answered before. How expensive is changing the mode? Is it just a status variable in user-space pthread lib? Or does it need a system call?
> 
> In other words, how fine granular can we get without incurring too high a cost?

It's expensive. We've seen it cause significant slowdowns in Java->VM transitions.

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

PR Comment: https://git.openjdk.org/jdk/pull/18762#issuecomment-2053734174

From lmesnik at openjdk.org  Sun Apr 14 06:42:07 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sun, 14 Apr 2024 06:42:07 GMT
Subject: RFR: 8330131: Problemlist
 serviceability/jvmti/vthread/GetThreadStateMountedTest/GetThreadStateMountedTest.java
Message-ID: <91RKMUF-XBARvp7OFx-l-5u3TWQIqwgxSpXsvr25hKI=.fe6c772c-08ca-409a-a328-0209a3f1a7a8@github.com>

Please review the fix which excludes the test that failing intermittently.

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

Commit messages:
 - 8330131: Problemlist serviceability/jvmti/vthread/GetThreadStateMountedTest/GetThreadStateMountedTest.java

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

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

From dcubed at openjdk.org  Sun Apr 14 13:24:45 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Sun, 14 Apr 2024 13:24:45 GMT
Subject: RFR: 8330131: Problemlist
 serviceability/jvmti/vthread/GetThreadStateMountedTest/GetThreadStateMountedTest.java
In-Reply-To: <91RKMUF-XBARvp7OFx-l-5u3TWQIqwgxSpXsvr25hKI=.fe6c772c-08ca-409a-a328-0209a3f1a7a8@github.com>
References: <91RKMUF-XBARvp7OFx-l-5u3TWQIqwgxSpXsvr25hKI=.fe6c772c-08ca-409a-a328-0209a3f1a7a8@github.com>
Message-ID: <cMpzUioHxpGKydqTt3mVfXlF7MdnxLq-USOCUK-3g_k=.14b83618-c5c5-4d3a-b29f-e6d9527461a9@github.com>

On Sat, 13 Apr 2024 23:35:07 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Please review the fix which excludes the test that failing intermittently.

Thumbs up. This is a trivial fix.

You originally had 8330131 as a sub-task of 8318729 which has only a
single sighting. Then I realized you were also including 8318090 which
has 15 sightings. I made 8330131 a sub-task of the earlier/older bug:
8318090.

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

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18772#pullrequestreview-1999660646

From lmesnik at openjdk.org  Sun Apr 14 16:04:51 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sun, 14 Apr 2024 16:04:51 GMT
Subject: Integrated: 8330131: Problemlist
 serviceability/jvmti/vthread/GetThreadStateMountedTest/GetThreadStateMountedTest.java
In-Reply-To: <91RKMUF-XBARvp7OFx-l-5u3TWQIqwgxSpXsvr25hKI=.fe6c772c-08ca-409a-a328-0209a3f1a7a8@github.com>
References: <91RKMUF-XBARvp7OFx-l-5u3TWQIqwgxSpXsvr25hKI=.fe6c772c-08ca-409a-a328-0209a3f1a7a8@github.com>
Message-ID: <Y2ff98AN-ZDNdjZmSjsUMwEOO4FQLplqGgMnBoe64co=.04d35661-3610-4a8c-9b29-277c2a385f69@github.com>

On Sat, 13 Apr 2024 23:35:07 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Please review the fix which excludes the test that failing intermittently.

This pull request has now been integrated.

Changeset: 1abb8262
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1abb826210eda76a3dc8cf1c10e6df6f2413a87a
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8330131: Problemlist serviceability/jvmti/vthread/GetThreadStateMountedTest/GetThreadStateMountedTest.java

Reviewed-by: dcubed

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

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

From kvn at openjdk.org  Mon Apr 15 00:49:11 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 15 Apr 2024 00:49:11 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v2]
In-Reply-To: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
Message-ID: <5nXtplnwZ4JwdZyDeHo429kdcWRP3IfzZcxBrQEwFuU=.56eabc9c-c60f-4453-bb33-2bbb85b4fc7f@github.com>

> This is part of changes which try to reduce size of `nmethod` and `codeblob` data vs code in CodeCache.
> These changes reduced size of `nmethod` header from 288 to 240 bytes. From 304 to 256 in optimized VM:
> 
> Statistics for 1282 bytecoded nmethods for C2:
>  total in heap = 5560352 (100%)
>  header = 389728 (7.009053%)
> 
> vs
> 
> Statistics for 1298 bytecoded nmethods for C2:
>  total in heap  = 5766040 (100%)
>  header         = 332288 (5.762846%)
> 
> 
> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some fields were changed from `int` to `int16_t` with added corresponding asserts to make sure their values are fit into 16 bits.
> 
> I did additional cleanup after recent `CompiledMethod` removal.
> 
> Tested tier1-7,stress,xcomp and performance testing.

Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  Moved some fields initialization into init_defaults()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18768/files
  - new: https://git.openjdk.org/jdk/pull/18768/files/a0c46b86..488f1b92

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

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

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

From kvn at openjdk.org  Mon Apr 15 03:24:07 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 15 Apr 2024 03:24:07 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v3]
In-Reply-To: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
Message-ID: <jMqrswByOAiVWG4wYedLPtkftNhDdLJqbzyTpF1N2DE=.26ae646c-4bbb-4ef7-91d7-0adb401fb809@github.com>

> This is part of changes which try to reduce size of `nmethod` and `codeblob` data vs code in CodeCache.
> These changes reduced size of `nmethod` header from 288 to 240 bytes. From 304 to 256 in optimized VM:
> 
> Statistics for 1282 bytecoded nmethods for C2:
>  total in heap = 5560352 (100%)
>  header = 389728 (7.009053%)
> 
> vs
> 
> Statistics for 1298 bytecoded nmethods for C2:
>  total in heap  = 5766040 (100%)
>  header         = 332288 (5.762846%)
> 
> 
> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some fields were changed from `int` to `int16_t` with added corresponding asserts to make sure their values are fit into 16 bits.
> 
> I did additional cleanup after recent `CompiledMethod` removal.
> 
> Tested tier1-7,stress,xcomp and performance testing.

Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  Union fields which usages do not overlap

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18768/files
  - new: https://git.openjdk.org/jdk/pull/18768/files/488f1b92..13744e78

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

  Stats: 31 lines in 2 files changed: 15 ins; 13 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18768.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18768/head:pull/18768

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

From burban at openjdk.org  Mon Apr 15 08:35:42 2024
From: burban at openjdk.org (Bernhard Urban-Forster)
Date: Mon, 15 Apr 2024 08:35:42 GMT
Subject: RFR: 8330171: Lazy W^X switch implementation
In-Reply-To: <9eymaXovxUNFdkAkzojFQP5trwl_yyY0jE2GzcMEjR4=.02ee2ef9-c476-4c7c-9e4a-e021425c38bc@github.com>
References: <9eymaXovxUNFdkAkzojFQP5trwl_yyY0jE2GzcMEjR4=.02ee2ef9-c476-4c7c-9e4a-e021425c38bc@github.com>
Message-ID: <RccCLpcBzmE5HG415eFBvMaHEcPsq92INC7JBl80N8k=.1af1c97b-2404-4db9-b594-9e9fec38a57c@github.com>

On Fri, 12 Apr 2024 14:40:05 GMT, Sergey Nazarkin <snazarki at openjdk.org> wrote:

> An alternative for preemptively switching the W^X thread mode on macOS with an AArch64 CPU. This implementation triggers the switch in response to the SIGBUS signal if the *si_addr* belongs to the CodeCache area. With this approach, it is now feasible to eliminate all WX guards and avoid potentially costly operations. However, no significant improvement or degradation in performance has been observed.  Additionally, considering the issue with AsyncGetCallTrace, the patched JVM has been successfully operated with [asgct_bottom](https://github.com/parttimenerd/asgct_bottom) and [async-profiler](https://github.com/async-profiler/async-profiler). 
> 
> Additional testing:
> - [x] MacOS AArch64 server fastdebug *gtets*
> - [ ] MacOS AArch64 server fastdebug *jtreg:hotspot:tier4*
> - [ ] Benchmarking
> 
> @apangin and @parttimenerd could you please check the patch on your scenarios??

I agree that this PR effectively removes the whole idea behind JIT_MAP and thus is a bad idea security wise.  Still it has some value.

@snazarkin do you have numbers on how many transitions are done with your PR vs. the current state when running the same program?  That would give us a lower bound on the amount of transitions needed and define a goal for future improvements in that area.

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

PR Comment: https://git.openjdk.org/jdk/pull/18762#issuecomment-2056182560

From sspitsyn at openjdk.org  Mon Apr 15 11:36:05 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 15 Apr 2024 11:36:05 GMT
Subject: RFR: 8328741:
 serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java failed with
 unexpected owner
Message-ID: <qXonY64Tq0lRSrpqGH86L7qGC1lpTmNZtQk54HFbHG4=.08c6864e-b84b-48ff-90e3-4d0768b42c45@github.com>

This is the test issue. The `WaitingPT3` thread posted the `MonitorWait` event but has not released the `lockCheck` monitor yet. It has been fixed to wait for each `WaitingTask` thread to really reach the `WAITING` state. The same approach is used for `EnteringTask` threads. It has been fixed to wait for each `EnteringTask` thread to reach the `BLOCKED_ON_MONITOR` state.

Testing:
 - Reran the test `serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java` locally
 - TBD: submit the mach5 tiers 1-6 as well

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

Commit messages:
 - remove trailing spaces for a couple of lines
 - 8328741: serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java failed with unexpected owner

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

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

From snazarki at openjdk.org  Mon Apr 15 16:34:01 2024
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Mon, 15 Apr 2024 16:34:01 GMT
Subject: RFR: 8330171: Lazy W^X switch implementation
In-Reply-To: <RccCLpcBzmE5HG415eFBvMaHEcPsq92INC7JBl80N8k=.1af1c97b-2404-4db9-b594-9e9fec38a57c@github.com>
References: <9eymaXovxUNFdkAkzojFQP5trwl_yyY0jE2GzcMEjR4=.02ee2ef9-c476-4c7c-9e4a-e021425c38bc@github.com>
 <RccCLpcBzmE5HG415eFBvMaHEcPsq92INC7JBl80N8k=.1af1c97b-2404-4db9-b594-9e9fec38a57c@github.com>
Message-ID: <C40feDZ9aXj9-By9rGsyZiL8JfzTsZfDLOgZ9Lr5IOU=.b73e712d-1ea9-4143-b87d-1dc7e47b4828@github.com>

On Mon, 15 Apr 2024 08:33:25 GMT, Bernhard Urban-Forster <burban at openjdk.org> wrote:

> do you have numbers on how many transitions are done with your PR vs. the current state when running the same program?

With just simple **java -version** it is ~180 vs ~9500 (new vs old),  for **java -help** ~1120 vs ~86300. For the applications the ration is about the same.

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

PR Comment: https://git.openjdk.org/jdk/pull/18762#issuecomment-2057280998

From amenkov at openjdk.org  Mon Apr 15 21:14:12 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 15 Apr 2024 21:14:12 GMT
Subject: RFR: 8322043: HeapDumper should use parallel dump by default [v2]
In-Reply-To: <m5p4qFndNtWAo_wwbdHKSJqG2XIcxwn_3tcJAYXAwgA=.dd4128e5-9688-45da-919e-683f4f6c6a10@github.com>
References: <m5p4qFndNtWAo_wwbdHKSJqG2XIcxwn_3tcJAYXAwgA=.dd4128e5-9688-45da-919e-683f4f6c6a10@github.com>
Message-ID: <RL6dA_kDpkhvFV8Eykj_XNpH8myN3zNBNGlRU2QVcvA=.20e0f57e-1031-479a-ae5f-0c5d6a85f359@github.com>

> The fix makes VM heap dumping parallel by default.
> `jcmd GC.heap_dump` and `jmap -dump` had parallel dumping by default, the fix affects `HotSpotDiagnosticMXBean.dumpHeap()`, `-XX:+HeapDumpBeforeFullGC`, `-XX:+HeapDumpAfterFullGC` and `-XX:+HeapDumpOnOutOfMemoryError`.
> 
> Testing:
>   - manually tested different heap dump scenarios with `-Xlog:heapdump`;
>   - tier1,tier2,hs-tier5-svc;
>   - all reg.tests that use heap dump.

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  check free_memory for OOME

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18748/files
  - new: https://git.openjdk.org/jdk/pull/18748/files/8a66572e..7ae4806e

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

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

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

From lmesnik at openjdk.org  Mon Apr 15 21:37:59 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 15 Apr 2024 21:37:59 GMT
Subject: RFR: 8328741:
 serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java failed with
 unexpected owner
In-Reply-To: <qXonY64Tq0lRSrpqGH86L7qGC1lpTmNZtQk54HFbHG4=.08c6864e-b84b-48ff-90e3-4d0768b42c45@github.com>
References: <qXonY64Tq0lRSrpqGH86L7qGC1lpTmNZtQk54HFbHG4=.08c6864e-b84b-48ff-90e3-4d0768b42c45@github.com>
Message-ID: <_j7qabwHV8RLPB83DCz3kcqUgQTNnllHN-12nHB2_fQ=.b0e501a7-fede-4f9e-934d-ecdcd66c9fd1@github.com>

On Mon, 15 Apr 2024 06:47:24 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This is the test issue. The `WaitingPT3` thread posted the `MonitorWait` event but has not released the `lockCheck` monitor yet. It has been fixed to wait for each `WaitingTask` thread to really reach the `WAITING` state. The same approach is used for `EnteringTask` threads. It has been fixed to wait for each `EnteringTask` thread to reach the `BLOCKED_ON_MONITOR` state.
> 
> Testing:
>  - Reran the test `serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java` locally
>  - TBD: submit the mach5 tiers 1-6 as well

Changes requested by lmesnik (Reviewer).

test/hotspot/jtreg/serviceability/jvmti/ObjectMonitorUsage/libObjectMonitorUsage.cpp line 183:

> 181: 
> 182: static void wait_for_state(JNIEnv *jni, jthread thread, jint exp_state) {
> 183:   RawMonitorLocker rml(jvmti, jni, event_lock);

The event_lock name is misleading, there are no events anymore.
Also, I am not sure if this lock is needed at all. How it is used? 

I think that wait_for_state is a good candidate to be added in the library. With some additional doc about states.

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

PR Review: https://git.openjdk.org/jdk/pull/18778#pullrequestreview-2002207716
PR Review Comment: https://git.openjdk.org/jdk/pull/18778#discussion_r1566464641

From amenkov at openjdk.org  Mon Apr 15 23:18:54 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 15 Apr 2024 23:18:54 GMT
Subject: RFR: 8322043: HeapDumper should use parallel dump by default [v3]
In-Reply-To: <m5p4qFndNtWAo_wwbdHKSJqG2XIcxwn_3tcJAYXAwgA=.dd4128e5-9688-45da-919e-683f4f6c6a10@github.com>
References: <m5p4qFndNtWAo_wwbdHKSJqG2XIcxwn_3tcJAYXAwgA=.dd4128e5-9688-45da-919e-683f4f6c6a10@github.com>
Message-ID: <wYXpZGlcW9H9TuM_sosE7F1DTYGrxpsuiXn2QQDefmI=.a5b72739-9bf7-4624-aff1-59bf53bae5c8@github.com>

> The fix makes VM heap dumping parallel by default.
> `jcmd GC.heap_dump` and `jmap -dump` had parallel dumping by default, the fix affects `HotSpotDiagnosticMXBean.dumpHeap()`, `-XX:+HeapDumpBeforeFullGC`, `-XX:+HeapDumpAfterFullGC` and `-XX:+HeapDumpOnOutOfMemoryError`.
> 
> Testing:
>   - manually tested different heap dump scenarios with `-Xlog:heapdump`;
>   - tier1,tier2,hs-tier5-svc;
>   - all reg.tests that use heap dump.

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  check free_memory for OOME

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18748/files
  - new: https://git.openjdk.org/jdk/pull/18748/files/7ae4806e..f6db604f

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

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

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

From lmesnik at openjdk.org  Tue Apr 16 00:33:59 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 16 Apr 2024 00:33:59 GMT
Subject: RFR: 8188784:
 javax/management/notification/BroadcasterSupportDeadlockTest.java - TEST
 FAILED: deadlock
In-Reply-To: <SjE2qD8hJjpNsEKrYBEzJm--eJ3p21uZS7M6ydlB8ow=.1bd99464-5794-4cb6-80b6-3245e8b71c39@github.com>
References: <SjE2qD8hJjpNsEKrYBEzJm--eJ3p21uZS7M6ydlB8ow=.1bd99464-5794-4cb6-80b6-3245e8b71c39@github.com>
Message-ID: <hOfioQFVmMR-FT9T1oDOYjeF3IAKnpUkzkc7v8FjCk4=.f5fa1d34-defb-4357-b286-847abcdc3afe@github.com>

On Tue, 9 Apr 2024 11:08:31 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test incorrectly fails, although rarely, thinking its "thread 2" has deadlocked.
> A change of sleep will likely fix this, but there are other issues, so cleaning up the test a little.
> 
> Remove the probe for the ManagementFactory class, to check we are on jdk5 or later. 8-)
> 
> When sleeping, sleep 100, not 1ms, we don't need to spin fast and actually race with the other thread.
> 
> We have a 1000 iteration loop, but don't seem to use it.  We only check once then either return (pass), fail, or break (which is also fail).  Use the loop to check for the status change, which is likely what was intended.
> 
> Show the stackframes on all failures.

Marked as reviewed by lmesnik (Reviewer).

test/jdk/javax/management/notification/BroadcasterSupportDeadlockTest.java line 122:

> 120:         java.util.Map<Thread,StackTraceElement[]> traces = Thread.getAllStackTraces();
> 121:         showStackTrace("Thread 1", traces.get(t1));
> 122:         showStackTrace("Thread 2", traces.get(t2));

Could you please replace System.exit() with throwing Exception. Other looks good.

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

PR Review: https://git.openjdk.org/jdk/pull/18687#pullrequestreview-2002384686
PR Review Comment: https://git.openjdk.org/jdk/pull/18687#discussion_r1566573453

From dlong at openjdk.org  Tue Apr 16 01:34:03 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 16 Apr 2024 01:34:03 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v3]
In-Reply-To: <jMqrswByOAiVWG4wYedLPtkftNhDdLJqbzyTpF1N2DE=.26ae646c-4bbb-4ef7-91d7-0adb401fb809@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
 <jMqrswByOAiVWG4wYedLPtkftNhDdLJqbzyTpF1N2DE=.26ae646c-4bbb-4ef7-91d7-0adb401fb809@github.com>
Message-ID: <ffdwVY1kSPaLxnhN0QN1lFhzRYDOienn-hE7_tGowlU=.4c337c0e-688d-44d5-9a67-a9f995227a94@github.com>

On Mon, 15 Apr 2024 03:24:07 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> This is part of changes which try to reduce size of `nmethod` and `codeblob` data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From 304 to 248 in optimized VM:
>> 
>> Statistics for 1282 bytecoded nmethods for C2:
>>  total in heap = 5560352 (100%)
>>  header = 389728 (7.009053%)
>> 
>> vs
>> 
>> Statistics for 1322 bytecoded nmethods for C2:
>>  total in heap  = 8307120 (100%)
>>  header         = 327856 (3.946687%)
>> 
>> 
>> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some fields were changed from `int` to `int16_t` with added corresponding asserts to make sure their values are fit into 16 bits.
>> 
>> I did additional cleanup after recent `CompiledMethod` removal.
>> 
>> Tested tier1-7,stress,xcomp and performance testing.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Union fields which usages do not overlap

src/hotspot/share/code/codeBlob.cpp line 88:

> 86:   S390_ONLY(_ctable_offset(0) COMMA)
> 87:   _header_size((uint16_t)header_size),
> 88:   _frame_complete_offset((int16_t)frame_complete_offset),

Rather than a raw cast, it would be better to use checked_cast here, or better yet, change the incoming parameter types to match the field type.  That way, if the caller is passing a constant, the compiler can check it at compile time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566601934

From dlong at openjdk.org  Tue Apr 16 01:37:45 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 16 Apr 2024 01:37:45 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v3]
In-Reply-To: <jMqrswByOAiVWG4wYedLPtkftNhDdLJqbzyTpF1N2DE=.26ae646c-4bbb-4ef7-91d7-0adb401fb809@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
 <jMqrswByOAiVWG4wYedLPtkftNhDdLJqbzyTpF1N2DE=.26ae646c-4bbb-4ef7-91d7-0adb401fb809@github.com>
Message-ID: <cAgT12uXdSlAXc5iYSs5-_zWXDywBSm4IrBR9J4U-UE=.a6e69ccf-090d-4c88-ade7-d1c751d44e0d@github.com>

On Mon, 15 Apr 2024 03:24:07 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> This is part of changes which try to reduce size of `nmethod` and `codeblob` data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From 304 to 248 in optimized VM:
>> 
>> Statistics for 1282 bytecoded nmethods for C2:
>>  total in heap = 5560352 (100%)
>>  header = 389728 (7.009053%)
>> 
>> vs
>> 
>> Statistics for 1322 bytecoded nmethods for C2:
>>  total in heap  = 8307120 (100%)
>>  header         = 327856 (3.946687%)
>> 
>> 
>> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some fields were changed from `int` to `int16_t` with added corresponding asserts to make sure their values are fit into 16 bits.
>> 
>> I did additional cleanup after recent `CompiledMethod` removal.
>> 
>> Tested tier1-7,stress,xcomp and performance testing.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Union fields which usages do not overlap

src/hotspot/share/code/codeBlob.cpp line 120:

> 118: 
> 119:   _header_size((uint16_t)header_size),
> 120:   _frame_complete_offset((int16_t)CodeOffsets::frame_never_safe),

See above.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566604310

From yyang at openjdk.org  Tue Apr 16 02:04:00 2024
From: yyang at openjdk.org (Yi Yang)
Date: Tue, 16 Apr 2024 02:04:00 GMT
Subject: RFR: 8322043: HeapDumper should use parallel dump by default [v3]
In-Reply-To: <wYXpZGlcW9H9TuM_sosE7F1DTYGrxpsuiXn2QQDefmI=.a5b72739-9bf7-4624-aff1-59bf53bae5c8@github.com>
References: <m5p4qFndNtWAo_wwbdHKSJqG2XIcxwn_3tcJAYXAwgA=.dd4128e5-9688-45da-919e-683f4f6c6a10@github.com>
 <wYXpZGlcW9H9TuM_sosE7F1DTYGrxpsuiXn2QQDefmI=.a5b72739-9bf7-4624-aff1-59bf53bae5c8@github.com>
Message-ID: <2nQ3G624-WDRaIYNGmsNgZnVRzroVzOqYHSrCSohdPY=.291a8aeb-f9e6-4379-8359-2d65e1920388@github.com>

On Mon, 15 Apr 2024 23:18:54 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix makes VM heap dumping parallel by default.
>> `jcmd GC.heap_dump` and `jmap -dump` had parallel dumping by default, the fix affects `HotSpotDiagnosticMXBean.dumpHeap()`, `-XX:+HeapDumpBeforeFullGC`, `-XX:+HeapDumpAfterFullGC` and `-XX:+HeapDumpOnOutOfMemoryError`.
>> 
>> Testing:
>>   - manually tested different heap dump scenarios with `-Xlog:heapdump`;
>>   - tier1,tier2,hs-tier5-svc;
>>   - all reg.tests that use heap dump.
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   check free_memory for OOME

Looks good. Thanks for doing this!

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

Marked as reviewed by yyang (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18748#pullrequestreview-2002450373

From kvn at openjdk.org  Tue Apr 16 02:09:01 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 16 Apr 2024 02:09:01 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v3]
In-Reply-To: <ffdwVY1kSPaLxnhN0QN1lFhzRYDOienn-hE7_tGowlU=.4c337c0e-688d-44d5-9a67-a9f995227a94@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
 <jMqrswByOAiVWG4wYedLPtkftNhDdLJqbzyTpF1N2DE=.26ae646c-4bbb-4ef7-91d7-0adb401fb809@github.com>
 <ffdwVY1kSPaLxnhN0QN1lFhzRYDOienn-hE7_tGowlU=.4c337c0e-688d-44d5-9a67-a9f995227a94@github.com>
Message-ID: <V57wWhybVlYNCsZZ4_SzOLdj6INd7maHx6Uz1s4Ehhs=.1dea8f46-4434-44f4-afa3-34f11a754620@github.com>

On Tue, 16 Apr 2024 01:30:50 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Union fields which usages do not overlap
>
> src/hotspot/share/code/codeBlob.cpp line 88:
> 
>> 86:   S390_ONLY(_ctable_offset(0) COMMA)
>> 87:   _header_size((uint16_t)header_size),
>> 88:   _frame_complete_offset((int16_t)frame_complete_offset),
> 
> Rather than a raw cast, it would be better to use checked_cast here, or better yet, change the incoming parameter types to match the field type.  That way, if the caller is passing a constant, the compiler can check it at compile time.

Agree and will do. In all case `sizeof(_Class_)` is used for `header_size`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566620168

From dlong at openjdk.org  Tue Apr 16 02:31:00 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 16 Apr 2024 02:31:00 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v3]
In-Reply-To: <jMqrswByOAiVWG4wYedLPtkftNhDdLJqbzyTpF1N2DE=.26ae646c-4bbb-4ef7-91d7-0adb401fb809@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
 <jMqrswByOAiVWG4wYedLPtkftNhDdLJqbzyTpF1N2DE=.26ae646c-4bbb-4ef7-91d7-0adb401fb809@github.com>
Message-ID: <vMLRKntp_CBc4iQmH27vKOlmQN6mZIbYk2hs0WJHE_0=.11a91b01-8af0-40d4-a8f5-8a3c7df5dfae@github.com>

On Mon, 15 Apr 2024 03:24:07 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> This is part of changes which try to reduce size of `nmethod` and `codeblob` data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From 304 to 248 in optimized VM:
>> 
>> Statistics for 1282 bytecoded nmethods for C2:
>>  total in heap = 5560352 (100%)
>>  header = 389728 (7.009053%)
>> 
>> vs
>> 
>> Statistics for 1322 bytecoded nmethods for C2:
>>  total in heap  = 8307120 (100%)
>>  header         = 327856 (3.946687%)
>> 
>> 
>> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some fields were changed from `int` to `int16_t` with added corresponding asserts to make sure their values are fit into 16 bits.
>> 
>> I did additional cleanup after recent `CompiledMethod` removal.
>> 
>> Tested tier1-7,stress,xcomp and performance testing.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Union fields which usages do not overlap

src/hotspot/share/code/nmethod.hpp line 282:

> 280:           _has_flushed_dependencies:1, // Used for maintenance of dependencies (under CodeCache_lock)
> 281:           _is_unlinked:1,              // mark during class unloading
> 282:           _load_reported:1;            // used by jvmti to track if an event has been posted for this nmethod

It seems like the type could be changed from uint8_t to bool.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566631312

From dlong at openjdk.org  Tue Apr 16 02:36:59 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 16 Apr 2024 02:36:59 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v3]
In-Reply-To: <jMqrswByOAiVWG4wYedLPtkftNhDdLJqbzyTpF1N2DE=.26ae646c-4bbb-4ef7-91d7-0adb401fb809@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
 <jMqrswByOAiVWG4wYedLPtkftNhDdLJqbzyTpF1N2DE=.26ae646c-4bbb-4ef7-91d7-0adb401fb809@github.com>
Message-ID: <qg_buJjFwuYFYTJ2TS9eo3MmLQCMuT-o_mFh3tBCM68=.78d3f339-9136-4564-8ff0-f49df5dae745@github.com>

On Mon, 15 Apr 2024 03:24:07 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> This is part of changes which try to reduce size of `nmethod` and `codeblob` data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From 304 to 248 in optimized VM:
>> 
>> Statistics for 1282 bytecoded nmethods for C2:
>>  total in heap = 5560352 (100%)
>>  header = 389728 (7.009053%)
>> 
>> vs
>> 
>> Statistics for 1322 bytecoded nmethods for C2:
>>  total in heap  = 8307120 (100%)
>>  header         = 327856 (3.946687%)
>> 
>> 
>> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some fields were changed from `int` to `int16_t` with added corresponding asserts to make sure their values are fit into 16 bits.
>> 
>> I did additional cleanup after recent `CompiledMethod` removal.
>> 
>> Tested tier1-7,stress,xcomp and performance testing.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Union fields which usages do not overlap

src/hotspot/share/code/nmethod.hpp line 205:

> 203:       // offsets to find the receiver for non-static native wrapper frames.
> 204:       ByteSize _native_receiver_sp_offset;
> 205:       ByteSize _native_basic_lock_sp_offset;

Don't we need an assert in the accessor functions to make sure nmethod is native or not?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566634384

From kvn at openjdk.org  Tue Apr 16 03:09:00 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 16 Apr 2024 03:09:00 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v3]
In-Reply-To: <qg_buJjFwuYFYTJ2TS9eo3MmLQCMuT-o_mFh3tBCM68=.78d3f339-9136-4564-8ff0-f49df5dae745@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
 <jMqrswByOAiVWG4wYedLPtkftNhDdLJqbzyTpF1N2DE=.26ae646c-4bbb-4ef7-91d7-0adb401fb809@github.com>
 <qg_buJjFwuYFYTJ2TS9eo3MmLQCMuT-o_mFh3tBCM68=.78d3f339-9136-4564-8ff0-f49df5dae745@github.com>
Message-ID: <64kGNHR9SmKW6rkPphO1my45Rte6w07v9V7Nf04GNN4=.0ac11f40-5e92-4367-82be-95410dca6ee5@github.com>

On Tue, 16 Apr 2024 02:34:29 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Union fields which usages do not overlap
>
> src/hotspot/share/code/nmethod.hpp line 205:
> 
>> 203:       // offsets to find the receiver for non-static native wrapper frames.
>> 204:       ByteSize _native_receiver_sp_offset;
>> 205:       ByteSize _native_basic_lock_sp_offset;
> 
> Don't we need an assert in the accessor functions to make sure nmethod is native or not?

I thought about that but in both places where these accessors are called (`frame::get_native_monitor()` and `frame::get_native_receiver()`) there are such asserts already:
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/frame.cpp#L1085

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566650267

From kvn at openjdk.org  Tue Apr 16 03:15:45 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 16 Apr 2024 03:15:45 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v3]
In-Reply-To: <vMLRKntp_CBc4iQmH27vKOlmQN6mZIbYk2hs0WJHE_0=.11a91b01-8af0-40d4-a8f5-8a3c7df5dfae@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
 <jMqrswByOAiVWG4wYedLPtkftNhDdLJqbzyTpF1N2DE=.26ae646c-4bbb-4ef7-91d7-0adb401fb809@github.com>
 <vMLRKntp_CBc4iQmH27vKOlmQN6mZIbYk2hs0WJHE_0=.11a91b01-8af0-40d4-a8f5-8a3c7df5dfae@github.com>
Message-ID: <IMRfi7_ZycPsowdgIi_PlMAK0eAsNPjS_TshZ4xpXOg=.95d16471-9e30-48a4-a85a-65750340c4e0@github.com>

On Tue, 16 Apr 2024 02:28:14 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Union fields which usages do not overlap
>
> src/hotspot/share/code/nmethod.hpp line 282:
> 
>> 280:           _has_flushed_dependencies:1, // Used for maintenance of dependencies (under CodeCache_lock)
>> 281:           _is_unlinked:1,              // mark during class unloading
>> 282:           _load_reported:1;            // used by jvmti to track if an event has been posted for this nmethod
> 
> It seems like the type could be changed from uint8_t to bool.

Is there difference in generated code when you use bool instead of uint8_t?
I used uint8_t to easy change to uint16_t in a future if needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566653582

From kvn at openjdk.org  Tue Apr 16 03:31:25 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 16 Apr 2024 03:31:25 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v4]
In-Reply-To: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
Message-ID: <j3YYM1ZnxcYxXAio_cQ3c60_SyLpsFgsCQ-sekOfe_w=.16d895c8-93c0-4825-bedd-6aa701708743@github.com>

> This is part of changes which try to reduce size of `nmethod` and `codeblob` data vs code in CodeCache.
> These changes reduced size of `nmethod` header from 288 to 232 bytes. From 304 to 248 in optimized VM:
> 
> Statistics for 1282 bytecoded nmethods for C2:
>  total in heap = 5560352 (100%)
>  header = 389728 (7.009053%)
> 
> vs
> 
> Statistics for 1322 bytecoded nmethods for C2:
>  total in heap  = 8307120 (100%)
>  header         = 327856 (3.946687%)
> 
> 
> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some fields were changed from `int` to `int16_t` with added corresponding asserts to make sure their values are fit into 16 bits.
> 
> I did additional cleanup after recent `CompiledMethod` removal.
> 
> Tested tier1-7,stress,xcomp and performance testing.

Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  Use 16-bits types for header_size and frame_complete_offset arguments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18768/files
  - new: https://git.openjdk.org/jdk/pull/18768/files/13744e78..6cb22e81

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

  Stats: 22 lines in 2 files changed: 0 ins; 2 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/18768.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18768/head:pull/18768

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

From sspitsyn at openjdk.org  Tue Apr 16 06:08:58 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 16 Apr 2024 06:08:58 GMT
Subject: RFR: 8328741:
 serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java failed with
 unexpected owner [v2]
In-Reply-To: <qXonY64Tq0lRSrpqGH86L7qGC1lpTmNZtQk54HFbHG4=.08c6864e-b84b-48ff-90e3-4d0768b42c45@github.com>
References: <qXonY64Tq0lRSrpqGH86L7qGC1lpTmNZtQk54HFbHG4=.08c6864e-b84b-48ff-90e3-4d0768b42c45@github.com>
Message-ID: <lMfA2jjzowr6QCwVdCo5AwJf60Q-enozLDHhJ2VRJU0=.5536a2c3-d5fa-484a-925d-912ec496a77d@github.com>

> This is the test issue. The `WaitingPT3` thread posted the `MonitorWait` event but has not released the `lockCheck` monitor yet. It has been fixed to wait for each `WaitingTask` thread to really reach the `WAITING` state. The same approach is used for `EnteringTask` threads. It has been fixed to wait for each `EnteringTask` thread to reach the `BLOCKED_ON_MONITOR` state.
> 
> Testing:
>  - Reran the test `serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java` locally
>  - TBD: submit the mach5 tiers 1-6 as well

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

  review: removed event_lock; moved wait_for_state() to jvmti_common.hpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18778/files
  - new: https://git.openjdk.org/jdk/pull/18778/files/1a1cde71..9941c492

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

  Stats: 38 lines in 2 files changed: 18 ins; 18 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/18778.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18778/head:pull/18778

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

From sspitsyn at openjdk.org  Tue Apr 16 06:08:58 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 16 Apr 2024 06:08:58 GMT
Subject: RFR: 8328741:
 serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java failed with
 unexpected owner [v2]
In-Reply-To: <_j7qabwHV8RLPB83DCz3kcqUgQTNnllHN-12nHB2_fQ=.b0e501a7-fede-4f9e-934d-ecdcd66c9fd1@github.com>
References: <qXonY64Tq0lRSrpqGH86L7qGC1lpTmNZtQk54HFbHG4=.08c6864e-b84b-48ff-90e3-4d0768b42c45@github.com>
 <_j7qabwHV8RLPB83DCz3kcqUgQTNnllHN-12nHB2_fQ=.b0e501a7-fede-4f9e-934d-ecdcd66c9fd1@github.com>
Message-ID: <_cMHocUTBMY6BJvbHvYTeGU5DoiKubuTXOQDNLrptIU=.bb55dc7d-69fd-49c1-a2b4-6f211921c510@github.com>

On Mon, 15 Apr 2024 21:34:48 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: removed event_lock; moved wait_for_state() to jvmti_common.hpp
>
> test/hotspot/jtreg/serviceability/jvmti/ObjectMonitorUsage/libObjectMonitorUsage.cpp line 183:
> 
>> 181: 
>> 182: static void wait_for_state(JNIEnv *jni, jthread thread, jint exp_state) {
>> 183:   RawMonitorLocker rml(jvmti, jni, event_lock);
> 
> The event_lock name is misleading, there are no events anymore.
> Also, I am not sure if this lock is needed at all. How it is used? 
> 
> I think that wait_for_state is a good candidate to be added in the library. With some additional doc about states.

Good suggestions, thanks. Implemented now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18778#discussion_r1566755184

From dlong at openjdk.org  Tue Apr 16 06:17:00 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 16 Apr 2024 06:17:00 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v3]
In-Reply-To: <jMqrswByOAiVWG4wYedLPtkftNhDdLJqbzyTpF1N2DE=.26ae646c-4bbb-4ef7-91d7-0adb401fb809@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
 <jMqrswByOAiVWG4wYedLPtkftNhDdLJqbzyTpF1N2DE=.26ae646c-4bbb-4ef7-91d7-0adb401fb809@github.com>
Message-ID: <EOhsDK7-ekMevDMMaB6B27pU4yajQHbiESSc9vCnui0=.01db9c3e-1214-4655-8f70-815c65056b19@github.com>

On Mon, 15 Apr 2024 03:24:07 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> This is part of changes which try to reduce size of `nmethod` and `codeblob` data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From 304 to 248 in optimized VM:
>> 
>> Statistics for 1282 bytecoded nmethods for C2:
>>  total in heap = 5560352 (100%)
>>  header = 389728 (7.009053%)
>> 
>> vs
>> 
>> Statistics for 1322 bytecoded nmethods for C2:
>>  total in heap  = 8307120 (100%)
>>  header         = 327856 (3.946687%)
>> 
>> 
>> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some fields were changed from `int` to `int16_t` with added corresponding asserts to make sure their values are fit into 16 bits.
>> 
>> I did additional cleanup after recent `CompiledMethod` removal.
>> 
>> Tested tier1-7,stress,xcomp and performance testing.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Union fields which usages do not overlap

src/hotspot/share/code/nmethod.cpp line 1235:

> 1233:     int skipped_insts_size   = code_buffer->total_skipped_instructions_size();
> 1234: #ifdef ASSERT
> 1235:     assert(((skipped_insts_size >> 16) == 0), "size is bigger than 64Kb: %d", skipped_insts_size);

Suggestion:


I think it's simpler just to use checked_cast below.

src/hotspot/share/code/nmethod.cpp line 1240:

> 1238:     int consts_offset = code_buffer->total_offset_of(code_buffer->consts());
> 1239:     assert(consts_offset == 0, "const_offset: %d", consts_offset);
> 1240: #endif

Suggestion:

src/hotspot/share/code/nmethod.cpp line 1241:

> 1239:     assert(consts_offset == 0, "const_offset: %d", consts_offset);
> 1240: #endif
> 1241:     _skipped_instructions_size = (uint16_t)skipped_insts_size;

Suggestion:

    _skipped_instructions_size = checked_cast<uint16_t>(code_buffer->total_skipped_instructions_size());

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566764300
PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566765068
PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566759786

From dlong at openjdk.org  Tue Apr 16 06:23:02 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 16 Apr 2024 06:23:02 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v3]
In-Reply-To: <jMqrswByOAiVWG4wYedLPtkftNhDdLJqbzyTpF1N2DE=.26ae646c-4bbb-4ef7-91d7-0adb401fb809@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
 <jMqrswByOAiVWG4wYedLPtkftNhDdLJqbzyTpF1N2DE=.26ae646c-4bbb-4ef7-91d7-0adb401fb809@github.com>
Message-ID: <ZHxLTT_9uLICvr5QQ2P-5rcC8anxr7ecBwnRV5vOprQ=.4b4377f6-b588-4546-b643-cb8021259424@github.com>

On Mon, 15 Apr 2024 03:24:07 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> This is part of changes which try to reduce size of `nmethod` and `codeblob` data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From 304 to 248 in optimized VM:
>> 
>> Statistics for 1282 bytecoded nmethods for C2:
>>  total in heap = 5560352 (100%)
>>  header = 389728 (7.009053%)
>> 
>> vs
>> 
>> Statistics for 1322 bytecoded nmethods for C2:
>>  total in heap  = 8307120 (100%)
>>  header         = 327856 (3.946687%)
>> 
>> 
>> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some fields were changed from `int` to `int16_t` with added corresponding asserts to make sure their values are fit into 16 bits.
>> 
>> I did additional cleanup after recent `CompiledMethod` removal.
>> 
>> Tested tier1-7,stress,xcomp and performance testing.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Union fields which usages do not overlap

src/hotspot/share/code/nmethod.cpp line 1441:

> 1439:     int deps_size     = align_up((int)dependencies->size_in_bytes(), oopSize);
> 1440:     int sum_size      = oops_size + metadata_size + deps_size;
> 1441:     assert((sum_size >> 16) == 0, "data size is bigger than 64Kb: %d", sum_size);

I suggest using checked_cast for the assignment below, rather than special-purpose checks here.

src/hotspot/share/code/nmethod.cpp line 1445:

> 1443:     _metadata_offset      = (uint16_t)oops_size;
> 1444:     _dependencies_offset  = _metadata_offset      + (uint16_t)metadata_size;
> 1445:     _scopes_pcs_offset    = _dependencies_offset  + (uint16_t)deps_size;

Use checked_cast instead of raw casts.

src/hotspot/share/code/nmethod.cpp line 1459:

> 1457:     assert((data_offset() + data_end_offset) <= nmethod_size, "wrong nmethod's size: %d < %d", nmethod_size, (data_offset() + data_end_offset));
> 1458: 
> 1459:     _entry_offset          = (uint16_t)offsets->value(CodeOffsets::Entry);

Use checked_cast.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566771026
PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566772567
PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566773477

From dlong at openjdk.org  Tue Apr 16 06:35:02 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 16 Apr 2024 06:35:02 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v3]
In-Reply-To: <jMqrswByOAiVWG4wYedLPtkftNhDdLJqbzyTpF1N2DE=.26ae646c-4bbb-4ef7-91d7-0adb401fb809@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
 <jMqrswByOAiVWG4wYedLPtkftNhDdLJqbzyTpF1N2DE=.26ae646c-4bbb-4ef7-91d7-0adb401fb809@github.com>
Message-ID: <dEB5Ux_kfsfZimL6VXvY6XMML2xUkB3tR1iNhadHic0=.c1a869a7-fa7d-4bfb-bfde-10e31342f262@github.com>

On Mon, 15 Apr 2024 03:24:07 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> This is part of changes which try to reduce size of `nmethod` and `codeblob` data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From 304 to 248 in optimized VM:
>> 
>> Statistics for 1282 bytecoded nmethods for C2:
>>  total in heap = 5560352 (100%)
>>  header = 389728 (7.009053%)
>> 
>> vs
>> 
>> Statistics for 1322 bytecoded nmethods for C2:
>>  total in heap  = 8307120 (100%)
>>  header         = 327856 (3.946687%)
>> 
>> 
>> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some fields were changed from `int` to `int16_t` with added corresponding asserts to make sure their values are fit into 16 bits.
>> 
>> I did additional cleanup after recent `CompiledMethod` removal.
>> 
>> Tested tier1-7,stress,xcomp and performance testing.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Union fields which usages do not overlap

src/hotspot/share/memory/heap.hpp line 58:

> 56:   void set_length(size_t length)                 {
> 57:     LP64_ONLY( assert(((length >> 32) == 0), "sanity"); )
> 58:     _header._length = (uint32_t)length;

Suggestion:

    _header._length = checked_cast<uint32_t>length;

src/hotspot/share/memory/heap.hpp line 63:

> 61:   // Accessors
> 62:   void* allocated_space() const                  { return (void*)(this + 1); }
> 63:   size_t length() const                          { return (size_t)_header._length; }

This cast looks unnecessary.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566784458
PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566784587

From dlong at openjdk.org  Tue Apr 16 06:50:43 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 16 Apr 2024 06:50:43 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v3]
In-Reply-To: <64kGNHR9SmKW6rkPphO1my45Rte6w07v9V7Nf04GNN4=.0ac11f40-5e92-4367-82be-95410dca6ee5@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
 <jMqrswByOAiVWG4wYedLPtkftNhDdLJqbzyTpF1N2DE=.26ae646c-4bbb-4ef7-91d7-0adb401fb809@github.com>
 <qg_buJjFwuYFYTJ2TS9eo3MmLQCMuT-o_mFh3tBCM68=.78d3f339-9136-4564-8ff0-f49df5dae745@github.com>
 <64kGNHR9SmKW6rkPphO1my45Rte6w07v9V7Nf04GNN4=.0ac11f40-5e92-4367-82be-95410dca6ee5@github.com>
Message-ID: <9wT-mL_BWh583PJEdw5DjgkbvqZB5abgPYsAUJMzTHA=.f62b51c8-b8c2-47b8-bcb5-57265523c75f@github.com>

On Tue, 16 Apr 2024 03:06:13 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> src/hotspot/share/code/nmethod.hpp line 205:
>> 
>>> 203:       // offsets to find the receiver for non-static native wrapper frames.
>>> 204:       ByteSize _native_receiver_sp_offset;
>>> 205:       ByteSize _native_basic_lock_sp_offset;
>> 
>> Don't we need an assert in the accessor functions to make sure nmethod is native or not?
>
> I thought about that but in both places where these accessors are called (`frame::get_native_monitor()` and `frame::get_native_receiver()`) there are such asserts already:
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/frame.cpp#L1085

OK, but I'd rather see it in the accessors too.  Some users are checking for method()->is_native() and others are checking for is_osr_method(), so we need to make sure those are always mutually exclusive: method()->is_native() != is_osr_method().

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566806754

From dlong at openjdk.org  Tue Apr 16 06:57:01 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 16 Apr 2024 06:57:01 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v3]
In-Reply-To: <IMRfi7_ZycPsowdgIi_PlMAK0eAsNPjS_TshZ4xpXOg=.95d16471-9e30-48a4-a85a-65750340c4e0@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
 <jMqrswByOAiVWG4wYedLPtkftNhDdLJqbzyTpF1N2DE=.26ae646c-4bbb-4ef7-91d7-0adb401fb809@github.com>
 <vMLRKntp_CBc4iQmH27vKOlmQN6mZIbYk2hs0WJHE_0=.11a91b01-8af0-40d4-a8f5-8a3c7df5dfae@github.com>
 <IMRfi7_ZycPsowdgIi_PlMAK0eAsNPjS_TshZ4xpXOg=.95d16471-9e30-48a4-a85a-65750340c4e0@github.com>
Message-ID: <R_H4xLgtHEXTA-tgdvxUGLuUFjqBtXz1nrXCZxeiE7c=.4917dccb-7ecd-481f-9d76-f55008334d72@github.com>

On Tue, 16 Apr 2024 03:12:48 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> src/hotspot/share/code/nmethod.hpp line 282:
>> 
>>> 280:           _has_flushed_dependencies:1, // Used for maintenance of dependencies (under CodeCache_lock)
>>> 281:           _is_unlinked:1,              // mark during class unloading
>>> 282:           _load_reported:1;            // used by jvmti to track if an event has been posted for this nmethod
>> 
>> It seems like the type could be changed from uint8_t to bool.
>
> Is there difference in generated code when you use bool instead of uint8_t?
> I used uint8_t to easy change to uint16_t in a future if needed.

I don't think uint8_t vs uint16_t matters, only if it is signed, unsigned, or bool.  So if we have more than 8 individual :1 fields, it will expand to a 2nd byte.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1566814258

From dholmes at openjdk.org  Tue Apr 16 09:11:43 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 16 Apr 2024 09:11:43 GMT
Subject: RFR: 8322043: HeapDumper should use parallel dump by default [v3]
In-Reply-To: <wYXpZGlcW9H9TuM_sosE7F1DTYGrxpsuiXn2QQDefmI=.a5b72739-9bf7-4624-aff1-59bf53bae5c8@github.com>
References: <m5p4qFndNtWAo_wwbdHKSJqG2XIcxwn_3tcJAYXAwgA=.dd4128e5-9688-45da-919e-683f4f6c6a10@github.com>
 <wYXpZGlcW9H9TuM_sosE7F1DTYGrxpsuiXn2QQDefmI=.a5b72739-9bf7-4624-aff1-59bf53bae5c8@github.com>
Message-ID: <nm3Aa-QUDBK-uDHIjKrkqLRU2SuXYsOU3gA4NP1k7KE=.e3bb85e5-73ba-471e-9358-0ee6117edd15@github.com>

On Mon, 15 Apr 2024 23:18:54 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix makes VM heap dumping parallel by default.
>> `jcmd GC.heap_dump` and `jmap -dump` had parallel dumping by default, the fix affects `HotSpotDiagnosticMXBean.dumpHeap()`, `-XX:+HeapDumpBeforeFullGC`, `-XX:+HeapDumpAfterFullGC` and `-XX:+HeapDumpOnOutOfMemoryError`.
>> 
>> Testing:
>>   - manually tested different heap dump scenarios with `-Xlog:heapdump`;
>>   - tier1,tier2,hs-tier5-svc;
>>   - all reg.tests that use heap dump.
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   check free_memory for OOME

src/hotspot/share/services/heapDumper.hpp line 63:

> 61:   // additional info is written to out if not null.
> 62:   // compression >= 0 creates a gzipped file with the given compression level.
> 63:   // parallel_thread_num >= 0 indicates thread numbers of parallel object dump, -1 means "auto select".

I don't understand why you need to add `-1` to mean "auto-select" instead of just setting the default parameter to be `default_num_of_dump_threads()`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18748#discussion_r1567017789

From kevinw at openjdk.org  Tue Apr 16 09:26:58 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 16 Apr 2024 09:26:58 GMT
Subject: RFR: 8188784:
 javax/management/notification/BroadcasterSupportDeadlockTest.java - TEST
 FAILED: deadlock [v2]
In-Reply-To: <SjE2qD8hJjpNsEKrYBEzJm--eJ3p21uZS7M6ydlB8ow=.1bd99464-5794-4cb6-80b6-3245e8b71c39@github.com>
References: <SjE2qD8hJjpNsEKrYBEzJm--eJ3p21uZS7M6ydlB8ow=.1bd99464-5794-4cb6-80b6-3245e8b71c39@github.com>
Message-ID: <zNYQk_LWVIte9YYR3Qjpj6OYqmUuYhCjkhoBZR2b75k=.6d622898-3eb1-414a-99a9-7fd46c8565e6@github.com>

> This test incorrectly fails, although rarely, thinking its "thread 2" has deadlocked.
> A change of sleep will likely fix this, but there are other issues, so cleaning up the test a little.
> 
> Remove the probe for the ManagementFactory class, to check we are on jdk5 or later. 8-)
> 
> When sleeping, sleep 100, not 1ms, we don't need to spin fast and actually race with the other thread.
> 
> We have a 1000 iteration loop, but don't seem to use it.  We only check once then either return (pass), fail, or break (which is also fail).  Use the loop to check for the status change, which is likely what was intended.
> 
> Show the stackframes on all failures.

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

 - Remove System.exit calls
 - Merge remote-tracking branch 'upstream/master' into 8188784_BroadcasterSupportDeadlockTest
 - 8188784: javax/management/notification/BroadcasterSupportDeadlockTest.java - TEST FAILED: deadlock

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18687/files
  - new: https://git.openjdk.org/jdk/pull/18687/files/5237f1d8..a77b3c85

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

  Stats: 16713 lines in 561 files changed: 8813 ins; 4016 del; 3884 mod
  Patch: https://git.openjdk.org/jdk/pull/18687.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18687/head:pull/18687

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

From kevinw at openjdk.org  Tue Apr 16 10:11:00 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 16 Apr 2024 10:11:00 GMT
Subject: RFR: 8188784:
 javax/management/notification/BroadcasterSupportDeadlockTest.java - TEST
 FAILED: deadlock [v2]
In-Reply-To: <hOfioQFVmMR-FT9T1oDOYjeF3IAKnpUkzkc7v8FjCk4=.f5fa1d34-defb-4357-b286-847abcdc3afe@github.com>
References: <SjE2qD8hJjpNsEKrYBEzJm--eJ3p21uZS7M6ydlB8ow=.1bd99464-5794-4cb6-80b6-3245e8b71c39@github.com>
 <hOfioQFVmMR-FT9T1oDOYjeF3IAKnpUkzkc7v8FjCk4=.f5fa1d34-defb-4357-b286-847abcdc3afe@github.com>
Message-ID: <YUvduyikE_xss-IuI9nbJN0MM6NWAue8K2yTTpBj4-E=.11b13182-ded4-4b77-ad85-1d14eb12a4ec@github.com>

On Tue, 16 Apr 2024 00:31:10 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Kevin Walls 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:
>> 
>>  - Remove System.exit calls
>>  - Merge remote-tracking branch 'upstream/master' into 8188784_BroadcasterSupportDeadlockTest
>>  - 8188784: javax/management/notification/BroadcasterSupportDeadlockTest.java - TEST FAILED: deadlock
>
> test/jdk/javax/management/notification/BroadcasterSupportDeadlockTest.java line 122:
> 
>> 120:         java.util.Map<Thread,StackTraceElement[]> traces = Thread.getAllStackTraces();
>> 121:         showStackTrace("Thread 1", traces.get(t1));
>> 122:         showStackTrace("Thread 2", traces.get(t2));
> 
> Could you please replace System.exit() with throwing Exception. Other looks good.

OK sure.
FYI I count 137 System.exit calls in test/jdk/javax/management
That's after I take out the existing 3 that are in this test. 8-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18687#discussion_r1567098465

From kevinw at openjdk.org  Tue Apr 16 10:24:09 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 16 Apr 2024 10:24:09 GMT
Subject: RFR: 8188784:
 javax/management/notification/BroadcasterSupportDeadlockTest.java - TEST
 FAILED: deadlock [v2]
In-Reply-To: <zNYQk_LWVIte9YYR3Qjpj6OYqmUuYhCjkhoBZR2b75k=.6d622898-3eb1-414a-99a9-7fd46c8565e6@github.com>
References: <SjE2qD8hJjpNsEKrYBEzJm--eJ3p21uZS7M6ydlB8ow=.1bd99464-5794-4cb6-80b6-3245e8b71c39@github.com>
 <zNYQk_LWVIte9YYR3Qjpj6OYqmUuYhCjkhoBZR2b75k=.6d622898-3eb1-414a-99a9-7fd46c8565e6@github.com>
Message-ID: <VR9cYyLlSnYr_daO-gDaRRsbulEPkcRSrHRSkCYqmXg=.fc4d3054-7b4e-4554-9886-e8bf8b52a38f@github.com>

On Tue, 16 Apr 2024 09:26:58 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> This test incorrectly fails, although rarely, thinking its "thread 2" has deadlocked.
>> A change of sleep will likely fix this, but there are other issues, so cleaning up the test a little.
>> 
>> Remove the probe for the ManagementFactory class, to check we are on jdk5 or later. 8-)
>> 
>> When sleeping, sleep 100, not 1ms, we don't need to spin fast and actually race with the other thread.
>> 
>> We have a 1000 iteration loop, but don't seem to use it.  We only check once then either return (pass), fail, or break (which is also fail).  Use the loop to check for the status change, which is likely what was intended.
>> 
>> Show the stackframes on all failures.
>
> Kevin Walls 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:
> 
>  - Remove System.exit calls
>  - Merge remote-tracking branch 'upstream/master' into 8188784_BroadcasterSupportDeadlockTest
>  - 8188784: javax/management/notification/BroadcasterSupportDeadlockTest.java - TEST FAILED: deadlock

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/18687#issuecomment-2058745011

From kevinw at openjdk.org  Tue Apr 16 10:24:09 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 16 Apr 2024 10:24:09 GMT
Subject: Integrated: 8188784:
 javax/management/notification/BroadcasterSupportDeadlockTest.java - TEST
 FAILED: deadlock
In-Reply-To: <SjE2qD8hJjpNsEKrYBEzJm--eJ3p21uZS7M6ydlB8ow=.1bd99464-5794-4cb6-80b6-3245e8b71c39@github.com>
References: <SjE2qD8hJjpNsEKrYBEzJm--eJ3p21uZS7M6ydlB8ow=.1bd99464-5794-4cb6-80b6-3245e8b71c39@github.com>
Message-ID: <92KFus1vIHrR2uVBvRzhSd51pXFqZ-tEopxHlaRd6Vg=.efce87cc-cce8-4722-8fbb-c1f397e3bc4b@github.com>

On Tue, 9 Apr 2024 11:08:31 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test incorrectly fails, although rarely, thinking its "thread 2" has deadlocked.
> A change of sleep will likely fix this, but there are other issues, so cleaning up the test a little.
> 
> Remove the probe for the ManagementFactory class, to check we are on jdk5 or later. 8-)
> 
> When sleeping, sleep 100, not 1ms, we don't need to spin fast and actually race with the other thread.
> 
> We have a 1000 iteration loop, but don't seem to use it.  We only check once then either return (pass), fail, or break (which is also fail).  Use the loop to check for the status change, which is likely what was intended.
> 
> Show the stackframes on all failures.

This pull request has now been integrated.

Changeset: 58911ccc
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/58911ccc2c48b4b5dd2ebc9d2a44dcf3737eca50
Stats:     42 lines in 1 file changed: 9 ins; 21 del; 12 mod

8188784: javax/management/notification/BroadcasterSupportDeadlockTest.java - TEST FAILED: deadlock

Reviewed-by: cjplummer, lmesnik

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

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

From jkratochvil at openjdk.org  Tue Apr 16 14:44:07 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 16 Apr 2024 14:44:07 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v2]
In-Reply-To: <trUwK5rQzvQtPnGLg7PeAvOdtPfJHFpEKdtyJcLj6Bw=.2435ad46-f513-4f20-952d-70c1b1f24924@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <trUwK5rQzvQtPnGLg7PeAvOdtPfJHFpEKdtyJcLj6Bw=.2435ad46-f513-4f20-952d-70c1b1f24924@github.com>
Message-ID: <E0c7XjQsTAjQ3oBR-9IrqKS-o6eaMrhYx2WxiRPEFJM=.af4c068c-e43e-460d-9b45-256df9205b28@github.com>

On Thu, 11 Apr 2024 12:08:02 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this enhancement to the container detection code which allows it to figure out whether the JVM is actually running inside a container (`podman`, `docker`, `crio`), or with some other means that enforces memory/cpu limits by means of the cgroup filesystem. If neither of those conditions hold, the JVM runs in not containerized mode, addressing the issue described in the JBS tracker. For example, on my Linux system `is_containerized() == false" is being indicated with the following trace log line:
>> 
>> 
>> [0.001s][debug][os,container] OSContainer::init: is_containerized() = false because no cpu or memory limit is present
>> 
>> 
>> This state is being exposed by the Java `Metrics` API class using the new (still JDK internal) `isContainerized()` method. Example:
>> 
>> 
>> java -XshowSettings:system --version
>> Operating System Metrics:
>>     Provider: cgroupv1
>>     System not containerized.
>> openjdk 23-internal 2024-09-17
>> OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk)
>> OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)
>> 
>> 
>> The basic property this is being built on is the observation that the cgroup controllers typically get mounted read only into containers. Note that the current container tests assert that `OSContainer::is_containerized() == true` in various tests. Therefore, using the heuristic of "is any memory or cpu limit present" isn't sufficient. I had considered that in an earlier iteration, but many container tests failed.
>> 
>> Overall, I think, with this patch we improve the current situation of claiming a containerized system being present when it's actually just a regular Linux system.
>> 
>> Testing:
>> 
>> - [x] GHA (risc-v failure seems infra related)
>> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including gtests)
>> - [x] Some manual testing using cri-o
>> 
>> Thoughts?
>
> 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 ten additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - jcheck fixes
>  - Fix tests
>  - Implement Metrics.isContainerized()
>  - Some clean-up
>  - Drop cgroups testing on plain Linux
>  - Implement fall-back logic for non-ro controller mounts
>  - Make find_ro static and local to compilation unit
>  - 8261242: [Linux] OSContainer::is_containerized() returns true

IMHO `is_containerized()` is OK to return `false` even when running in a container but with no limitations set.

Container detection is IIUC/AFAIK being used to maximize resource usage by OpenJDK. But if OpenJDK runs in a container with the same limits as the hardware box OpenJDK should still use reduced resources as it is sharing them with other processes on the hardware box.

[is-containerized.patch.txt](https://github.com/openjdk/jdk/files/14998503/is-containerized.patch.txt)

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

PR Comment: https://git.openjdk.org/jdk/pull/18201#issuecomment-2059261807

From sgehwolf at openjdk.org  Tue Apr 16 15:19:41 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 16 Apr 2024 15:19:41 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v2]
In-Reply-To: <E0c7XjQsTAjQ3oBR-9IrqKS-o6eaMrhYx2WxiRPEFJM=.af4c068c-e43e-460d-9b45-256df9205b28@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <trUwK5rQzvQtPnGLg7PeAvOdtPfJHFpEKdtyJcLj6Bw=.2435ad46-f513-4f20-952d-70c1b1f24924@github.com>
 <E0c7XjQsTAjQ3oBR-9IrqKS-o6eaMrhYx2WxiRPEFJM=.af4c068c-e43e-460d-9b45-256df9205b28@github.com>
Message-ID: <XpaCLyqit2xsq95Sou7z9clG7WWTwzIBR16ib0_xlDc=.376b07f0-3efd-4c85-a9c5-a61a4bdc0d61@github.com>

On Tue, 16 Apr 2024 14:40:46 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> IMHO `is_containerized()` is OK to return `false` even when running in a container but with no limitations set.

The idea here is to use this property to tune OpenJDK for in-container, specifically k8s, use. In such a setup it's custom to run a single process within set resource constraints. In order to do this, we need a reliable way to distinguish that vs. non-containerized setup. If somebody really wants to run OpenJDK in a container expecting it to run like a physical OpenJDK deployment, that's when `-XX:-UseContainerSupport` should be used.

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

PR Comment: https://git.openjdk.org/jdk/pull/18201#issuecomment-2059344194

From kvn at openjdk.org  Tue Apr 16 15:57:03 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 16 Apr 2024 15:57:03 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v3]
In-Reply-To: <9wT-mL_BWh583PJEdw5DjgkbvqZB5abgPYsAUJMzTHA=.f62b51c8-b8c2-47b8-bcb5-57265523c75f@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
 <jMqrswByOAiVWG4wYedLPtkftNhDdLJqbzyTpF1N2DE=.26ae646c-4bbb-4ef7-91d7-0adb401fb809@github.com>
 <qg_buJjFwuYFYTJ2TS9eo3MmLQCMuT-o_mFh3tBCM68=.78d3f339-9136-4564-8ff0-f49df5dae745@github.com>
 <64kGNHR9SmKW6rkPphO1my45Rte6w07v9V7Nf04GNN4=.0ac11f40-5e92-4367-82be-95410dca6ee5@github.com>
 <9wT-mL_BWh583PJEdw5DjgkbvqZB5abgPYsAUJMzTHA=.f62b51c8-b8c2-47b8-bcb5-57265523c75f@github.com>
Message-ID: <XpMjal-LPSagANXlpuuT-rhzQ_xai_ofUee_8EjETJk=.850a40ca-654a-4945-ab8c-256d2c773f5c@github.com>

On Tue, 16 Apr 2024 06:48:05 GMT, Dean Long <dlong at openjdk.org> wrote:

>> I thought about that but in both places where these accessors are called (`frame::get_native_monitor()` and `frame::get_native_receiver()`) there are such asserts already:
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/frame.cpp#L1085
>
> OK, but I'd rather see it in the accessors too.  Some users are checking for method()->is_native() and others are checking for is_osr_method(), so we need to make sure those are always mutually exclusive: method()->is_native() != is_osr_method().

We have separate `nmethod()` constructor for native method wrappers and it sets `_entry_bci = InvocationEntryBci;`. So it is impossible to have OSR native method wrapper.
But I agree with adding assert into accessors to catch accidental usage for not native methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1567603094

From kvn at openjdk.org  Tue Apr 16 16:27:43 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 16 Apr 2024 16:27:43 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v4]
In-Reply-To: <j3YYM1ZnxcYxXAio_cQ3c60_SyLpsFgsCQ-sekOfe_w=.16d895c8-93c0-4825-bedd-6aa701708743@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
 <j3YYM1ZnxcYxXAio_cQ3c60_SyLpsFgsCQ-sekOfe_w=.16d895c8-93c0-4825-bedd-6aa701708743@github.com>
Message-ID: <JFOZ6FRT_ZKw3casyyF2Pjr5Wcu0LGaBeH25N8VEJmU=.308f5194-8033-45ec-8e51-bbdf8c53d35a@github.com>

On Tue, 16 Apr 2024 03:31:25 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> This is part of changes which try to reduce size of `nmethod` and `codeblob` data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From 304 to 248 in optimized VM:
>> 
>> Statistics for 1282 bytecoded nmethods for C2:
>>  total in heap = 5560352 (100%)
>>  header = 389728 (7.009053%)
>> 
>> vs
>> 
>> Statistics for 1322 bytecoded nmethods for C2:
>>  total in heap  = 8307120 (100%)
>>  header         = 327856 (3.946687%)
>> 
>> 
>> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some fields were changed from `int` to `int16_t` with added corresponding asserts to make sure their values are fit into 16 bits.
>> 
>> I did additional cleanup after recent `CompiledMethod` removal.
>> 
>> Tested tier1-7,stress,xcomp and performance testing.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use 16-bits types for header_size and frame_complete_offset arguments

@dean-long, thank you for review. I applied all your suggestions and push it after testing.

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

PR Review: https://git.openjdk.org/jdk/pull/18768#pullrequestreview-2004070926

From kvn at openjdk.org  Tue Apr 16 16:27:47 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 16 Apr 2024 16:27:47 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v3]
In-Reply-To: <EOhsDK7-ekMevDMMaB6B27pU4yajQHbiESSc9vCnui0=.01db9c3e-1214-4655-8f70-815c65056b19@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
 <jMqrswByOAiVWG4wYedLPtkftNhDdLJqbzyTpF1N2DE=.26ae646c-4bbb-4ef7-91d7-0adb401fb809@github.com>
 <EOhsDK7-ekMevDMMaB6B27pU4yajQHbiESSc9vCnui0=.01db9c3e-1214-4655-8f70-815c65056b19@github.com>
Message-ID: <YsJ6qXdQorENXip_NL4kFVBhoJc5unYiTR1E4B5TSJ8=.acfda678-11a5-4ce4-9982-5a8114edd34c@github.com>

On Tue, 16 Apr 2024 06:13:59 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Union fields which usages do not overlap
>
> src/hotspot/share/code/nmethod.cpp line 1235:
> 
>> 1233:     int skipped_insts_size   = code_buffer->total_skipped_instructions_size();
>> 1234: #ifdef ASSERT
>> 1235:     assert(((skipped_insts_size >> 16) == 0), "size is bigger than 64Kb: %d", skipped_insts_size);
> 
> Suggestion:
> 
> 
> I think it's simpler just to use checked_cast below.

Agree

> src/hotspot/share/code/nmethod.cpp line 1240:
> 
>> 1238:     int consts_offset = code_buffer->total_offset_of(code_buffer->consts());
>> 1239:     assert(consts_offset == 0, "const_offset: %d", consts_offset);
>> 1240: #endif
> 
> Suggestion:

I assume you are suggesting to remove `#ifdef ASSERT`.
Done.

> src/hotspot/share/code/nmethod.cpp line 1241:
> 
>> 1239:     assert(consts_offset == 0, "const_offset: %d", consts_offset);
>> 1240: #endif
>> 1241:     _skipped_instructions_size = (uint16_t)skipped_insts_size;
> 
> Suggestion:
> 
>     _skipped_instructions_size = checked_cast<uint16_t>(code_buffer->total_skipped_instructions_size());

Done.

> src/hotspot/share/code/nmethod.cpp line 1441:
> 
>> 1439:     int deps_size     = align_up((int)dependencies->size_in_bytes(), oopSize);
>> 1440:     int sum_size      = oops_size + metadata_size + deps_size;
>> 1441:     assert((sum_size >> 16) == 0, "data size is bigger than 64Kb: %d", sum_size);
> 
> I suggest using checked_cast for the assignment below, rather than special-purpose checks here.

Okay. But I will put above code under `#ifdef ASSERT` then.

> src/hotspot/share/code/nmethod.cpp line 1445:
> 
>> 1443:     _metadata_offset      = (uint16_t)oops_size;
>> 1444:     _dependencies_offset  = _metadata_offset      + (uint16_t)metadata_size;
>> 1445:     _scopes_pcs_offset    = _dependencies_offset  + (uint16_t)deps_size;
> 
> Use checked_cast instead of raw casts.

okay

> src/hotspot/share/code/nmethod.cpp line 1459:
> 
>> 1457:     assert((data_offset() + data_end_offset) <= nmethod_size, "wrong nmethod's size: %d < %d", nmethod_size, (data_offset() + data_end_offset));
>> 1458: 
>> 1459:     _entry_offset          = (uint16_t)offsets->value(CodeOffsets::Entry);
> 
> Use checked_cast.

done

> src/hotspot/share/memory/heap.hpp line 58:
> 
>> 56:   void set_length(size_t length)                 {
>> 57:     LP64_ONLY( assert(((length >> 32) == 0), "sanity"); )
>> 58:     _header._length = (uint32_t)length;
> 
> Suggestion:
> 
>     _header._length = checked_cast<uint32_t>length;

Done.

> src/hotspot/share/memory/heap.hpp line 63:
> 
>> 61:   // Accessors
>> 62:   void* allocated_space() const                  { return (void*)(this + 1); }
>> 63:   size_t length() const                          { return (size_t)_header._length; }
> 
> This cast looks unnecessary.

Agree.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1567619512
PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1567620520
PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1567620735
PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1567627565
PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1567636013
PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1567638682
PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1567644204
PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1567645140

From coleenp at openjdk.org  Tue Apr 16 16:35:45 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 16 Apr 2024 16:35:45 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v4]
In-Reply-To: <j3YYM1ZnxcYxXAio_cQ3c60_SyLpsFgsCQ-sekOfe_w=.16d895c8-93c0-4825-bedd-6aa701708743@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
 <j3YYM1ZnxcYxXAio_cQ3c60_SyLpsFgsCQ-sekOfe_w=.16d895c8-93c0-4825-bedd-6aa701708743@github.com>
Message-ID: <DDnSgwl-rv0d-9GXciIsijYY8g6nSs3bayg79Rl-H58=.13ed38c2-c7c7-44f9-81c8-db9cbcccbed7@github.com>

On Tue, 16 Apr 2024 03:31:25 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> This is part of changes which try to reduce size of `nmethod` and `codeblob` data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From 304 to 248 in optimized VM:
>> 
>> Statistics for 1282 bytecoded nmethods for C2:
>>  total in heap = 5560352 (100%)
>>  header = 389728 (7.009053%)
>> 
>> vs
>> 
>> Statistics for 1322 bytecoded nmethods for C2:
>>  total in heap  = 8307120 (100%)
>>  header         = 327856 (3.946687%)
>> 
>> 
>> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some fields were changed from `int` to `int16_t` with added corresponding asserts to make sure their values are fit into 16 bits.
>> 
>> I did additional cleanup after recent `CompiledMethod` removal.
>> 
>> Tested tier1-7,stress,xcomp and performance testing.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use 16-bits types for header_size and frame_complete_offset arguments

src/hotspot/share/code/codeBlob.cpp line 106:

> 104: 
> 105: // Simple CodeBlob used for simple BufferBlob.
> 106: CodeBlob::CodeBlob(const char* name, CodeBlobKind kind, int size, uint16_t header_size) :

Just a drive-by comment.  You might be able to use delegating constructors for CodeBlob so you don't have to have the field initializations twice.  Maybe the same for nmethod ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1567658758

From stuefe at openjdk.org  Tue Apr 16 18:29:04 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 16 Apr 2024 18:29:04 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v2]
In-Reply-To: <trUwK5rQzvQtPnGLg7PeAvOdtPfJHFpEKdtyJcLj6Bw=.2435ad46-f513-4f20-952d-70c1b1f24924@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <trUwK5rQzvQtPnGLg7PeAvOdtPfJHFpEKdtyJcLj6Bw=.2435ad46-f513-4f20-952d-70c1b1f24924@github.com>
Message-ID: <8MpoLKDw6usz92EBH9R1XWfnX0E7NU5fd2dv8tob2ho=.455c310f-cadb-484d-a40f-6fd7e2c0811c@github.com>

On Thu, 11 Apr 2024 12:08:02 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this enhancement to the container detection code which allows it to figure out whether the JVM is actually running inside a container (`podman`, `docker`, `crio`), or with some other means that enforces memory/cpu limits by means of the cgroup filesystem. If neither of those conditions hold, the JVM runs in not containerized mode, addressing the issue described in the JBS tracker. For example, on my Linux system `is_containerized() == false" is being indicated with the following trace log line:
>> 
>> 
>> [0.001s][debug][os,container] OSContainer::init: is_containerized() = false because no cpu or memory limit is present
>> 
>> 
>> This state is being exposed by the Java `Metrics` API class using the new (still JDK internal) `isContainerized()` method. Example:
>> 
>> 
>> java -XshowSettings:system --version
>> Operating System Metrics:
>>     Provider: cgroupv1
>>     System not containerized.
>> openjdk 23-internal 2024-09-17
>> OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk)
>> OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)
>> 
>> 
>> The basic property this is being built on is the observation that the cgroup controllers typically get mounted read only into containers. Note that the current container tests assert that `OSContainer::is_containerized() == true` in various tests. Therefore, using the heuristic of "is any memory or cpu limit present" isn't sufficient. I had considered that in an earlier iteration, but many container tests failed.
>> 
>> Overall, I think, with this patch we improve the current situation of claiming a containerized system being present when it's actually just a regular Linux system.
>> 
>> Testing:
>> 
>> - [x] GHA (risc-v failure seems infra related)
>> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including gtests)
>> - [x] Some manual testing using cri-o
>> 
>> Thoughts?
>
> 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 ten additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - jcheck fixes
>  - Fix tests
>  - Implement Metrics.isContainerized()
>  - Some clean-up
>  - Drop cgroups testing on plain Linux
>  - Implement fall-back logic for non-ro controller mounts
>  - Make find_ro static and local to compilation unit
>  - 8261242: [Linux] OSContainer::is_containerized() returns true

I am not enough of a container expert to judge if the basic approach is right - I trust you on this. This is just a technical code review.

src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 170:

> 168:     }
> 169:   }
> 170:   return false;

An alternative, simpler, no need for modifying source string:

static bool find_ro_opt(const char* o) {
  return strcmp(o, "ro") || strstr(o, ",ro") || strstr(o, "ro,");
}

src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 351:

> 349:     //
> 350:     // We collect the read only mount option in the cgroup infos so as to have that
> 351:     // info ready when determining is_containerized().

Here, and in other places: a comment indicating the line format we scan would be appreciated, possibly with argument numbers. Saves the casual code reader from looking into proc man page. Even just pasting the example line for proc manpage would be fine (https://man7.org/linux/man-pages/man5/proc.5.html) (but with order adapted to your scanf call, they count major:minor as one)

src/hotspot/os/linux/osContainer_linux.cpp line 78:

> 76:   const char *reason;
> 77:   bool any_mem_cpu_limit_present = false;
> 78:   bool ctrl_ro = cgroup_subsystem->is_containerized();

nit: naming? what does ctrl mean in this case? Maybe use "cgroup_is_containerized"?

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 375:

> 373:         if (!c.isContainerized()) {
> 374:             ostream.println(INDENT + "System not containerized.");
> 375:             return;

Why return here? Would this not cut the output short in the non-containerized case?

And if this not intended, the not-containerized-`-XshowSettings:system` test below should test and catch this (e.g. scan for CPU set)

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

PR Review: https://git.openjdk.org/jdk/pull/18201#pullrequestreview-1999328503
PR Review Comment: https://git.openjdk.org/jdk/pull/18201#discussion_r1564182879
PR Review Comment: https://git.openjdk.org/jdk/pull/18201#discussion_r1567756663
PR Review Comment: https://git.openjdk.org/jdk/pull/18201#discussion_r1567774124
PR Review Comment: https://git.openjdk.org/jdk/pull/18201#discussion_r1567779248

From stuefe at openjdk.org  Tue Apr 16 18:29:05 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 16 Apr 2024 18:29:05 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v2]
In-Reply-To: <8MpoLKDw6usz92EBH9R1XWfnX0E7NU5fd2dv8tob2ho=.455c310f-cadb-484d-a40f-6fd7e2c0811c@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <trUwK5rQzvQtPnGLg7PeAvOdtPfJHFpEKdtyJcLj6Bw=.2435ad46-f513-4f20-952d-70c1b1f24924@github.com>
 <8MpoLKDw6usz92EBH9R1XWfnX0E7NU5fd2dv8tob2ho=.455c310f-cadb-484d-a40f-6fd7e2c0811c@github.com>
Message-ID: <HrCfJ_QTcggLdq-EC_tT7bfoAeDxjxYxzjONnP_RkA4=.5e5a2271-f25e-4eb1-a844-0bb2079149bb@github.com>

On Sat, 13 Apr 2024 18:29:59 GMT, Thomas Stuefe <stuefe 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 ten additional commits since the last revision:
>> 
>>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>>  - jcheck fixes
>>  - Fix tests
>>  - Implement Metrics.isContainerized()
>>  - Some clean-up
>>  - Drop cgroups testing on plain Linux
>>  - Implement fall-back logic for non-ro controller mounts
>>  - Make find_ro static and local to compilation unit
>>  - 8261242: [Linux] OSContainer::is_containerized() returns true
>
> src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 170:
> 
>> 168:     }
>> 169:   }
>> 170:   return false;
> 
> An alternative, simpler, no need for modifying source string:
> 
> static bool find_ro_opt(const char* o) {
>   return strcmp(o, "ro") || strstr(o, ",ro") || strstr(o, "ro,");
> }

Please disregard my comment. Albeit longer, your version is clearer to read and more fault tolerant.

> src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 351:
> 
>> 349:     //
>> 350:     // We collect the read only mount option in the cgroup infos so as to have that
>> 351:     // info ready when determining is_containerized().
> 
> Here, and in other places: a comment indicating the line format we scan would be appreciated, possibly with argument numbers. Saves the casual code reader from looking into proc man page. Even just pasting the example line for proc manpage would be fine (https://man7.org/linux/man-pages/man5/proc.5.html) (but with order adapted to your scanf call, they count major:minor as one)

Trying to parse the `%s%*[^-]-`

So, %s parses the mount options, until we encounter whitespace. Then %*[^-]- parses everything that is not a dash, until we encounter the dash? Then we eat the dash? This is to skip the optionals?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18201#discussion_r1567754861
PR Review Comment: https://git.openjdk.org/jdk/pull/18201#discussion_r1567767209

From kvn at openjdk.org  Tue Apr 16 18:36:11 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 16 Apr 2024 18:36:11 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v5]
In-Reply-To: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
Message-ID: <AUSfKBeIN3wFTYrj5kmxr-9jlRNXsHhmUIGNee5vxq8=.e59151a7-dff9-4252-988a-168cade301fe@github.com>

> This is part of changes which try to reduce size of `nmethod` and `codeblob` data vs code in CodeCache.
> These changes reduced size of `nmethod` header from 288 to 232 bytes. From 304 to 248 in optimized VM:
> 
> Statistics for 1282 bytecoded nmethods for C2:
>  total in heap = 5560352 (100%)
>  header = 389728 (7.009053%)
> 
> vs
> 
> Statistics for 1322 bytecoded nmethods for C2:
>  total in heap  = 8307120 (100%)
>  header         = 327856 (3.946687%)
> 
> 
> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some fields were changed from `int` to `int16_t` with added corresponding asserts to make sure their values are fit into 16 bits.
> 
> I did additional cleanup after recent `CompiledMethod` removal.
> 
> Tested tier1-7,stress,xcomp and performance testing.

Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  Address comments. Used checked_cast.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18768/files
  - new: https://git.openjdk.org/jdk/pull/18768/files/6cb22e81..8405a23d

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

  Stats: 32 lines in 3 files changed: 4 ins; 11 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/18768.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18768/head:pull/18768

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

From kvn at openjdk.org  Tue Apr 16 18:58:01 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 16 Apr 2024 18:58:01 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v4]
In-Reply-To: <DDnSgwl-rv0d-9GXciIsijYY8g6nSs3bayg79Rl-H58=.13ed38c2-c7c7-44f9-81c8-db9cbcccbed7@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
 <j3YYM1ZnxcYxXAio_cQ3c60_SyLpsFgsCQ-sekOfe_w=.16d895c8-93c0-4825-bedd-6aa701708743@github.com>
 <DDnSgwl-rv0d-9GXciIsijYY8g6nSs3bayg79Rl-H58=.13ed38c2-c7c7-44f9-81c8-db9cbcccbed7@github.com>
Message-ID: <drVa2X5_UJ2H4Y36ZmC95IU5YN4wPs-uqxWDNcGjUy4=.01088b0f-94dc-47fb-bee6-2379d26d59f3@github.com>

On Tue, 16 Apr 2024 16:33:18 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use 16-bits types for header_size and frame_complete_offset arguments
>
> src/hotspot/share/code/codeBlob.cpp line 106:
> 
>> 104: 
>> 105: // Simple CodeBlob used for simple BufferBlob.
>> 106: CodeBlob::CodeBlob(const char* name, CodeBlobKind kind, int size, uint16_t header_size) :
> 
> Just a drive-by comment.  You might be able to use delegating constructors for CodeBlob so you don't have to have the field initializations twice.  Maybe the same for nmethod ?

Thank you, @coleenp, foe looking on these changes.

Which fields are initialized twice? Only `_oop_maps` is set to `nullptr` before we proper build oop maps in first constructor.

The only saving could be lines of code but then I would have to check that `cb != nullptr` and do other additional checks which I don't think will save much lines.

Separation of `nmethod` constructor for native wrappers is helping clear see the difference and I would like to keep them separate. We have `init_defaults()` method for similar code and I can move more code into it from both constructors.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1567814189

From coleenp at openjdk.org  Tue Apr 16 19:06:05 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 16 Apr 2024 19:06:05 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v4]
In-Reply-To: <drVa2X5_UJ2H4Y36ZmC95IU5YN4wPs-uqxWDNcGjUy4=.01088b0f-94dc-47fb-bee6-2379d26d59f3@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
 <j3YYM1ZnxcYxXAio_cQ3c60_SyLpsFgsCQ-sekOfe_w=.16d895c8-93c0-4825-bedd-6aa701708743@github.com>
 <DDnSgwl-rv0d-9GXciIsijYY8g6nSs3bayg79Rl-H58=.13ed38c2-c7c7-44f9-81c8-db9cbcccbed7@github.com>
 <drVa2X5_UJ2H4Y36ZmC95IU5YN4wPs-uqxWDNcGjUy4=.01088b0f-94dc-47fb-bee6-2379d26d59f3@github.com>
Message-ID: <73tOotwsnkVfT0_0moY8U333EHAjV2MJ3amY6mMF58Y=.a5003aa6-4aea-4e20-82cc-0466403a9503@github.com>

On Tue, 16 Apr 2024 18:54:40 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> src/hotspot/share/code/codeBlob.cpp line 106:
>> 
>>> 104: 
>>> 105: // Simple CodeBlob used for simple BufferBlob.
>>> 106: CodeBlob::CodeBlob(const char* name, CodeBlobKind kind, int size, uint16_t header_size) :
>> 
>> Just a drive-by comment.  You might be able to use delegating constructors for CodeBlob so you don't have to have the field initializations twice.  Maybe the same for nmethod ?
>
> Thank you, @coleenp, foe looking on these changes.
> 
> Which fields are initialized twice? Only `_oop_maps` is set to `nullptr` before we proper build oop maps in first constructor.
> 
> The only saving could be lines of code but then I would have to check that `cb != nullptr` and do other additional checks which I don't think will save much lines.
> 
> Separation of `nmethod` constructor for native wrappers is helping clear see the difference and I would like to keep them separate. We have `init_defaults()` method for similar code and I can move more code into it from both constructors.

Delegating constructors are the answer to having some common 'init' functions.  It would simply save lines of code that look the same in both constructor initializer lists.  But it's a drive-by comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1567823393

From lmesnik at openjdk.org  Tue Apr 16 19:23:41 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 16 Apr 2024 19:23:41 GMT
Subject: RFR: 8328741:
 serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java failed with
 unexpected owner [v2]
In-Reply-To: <lMfA2jjzowr6QCwVdCo5AwJf60Q-enozLDHhJ2VRJU0=.5536a2c3-d5fa-484a-925d-912ec496a77d@github.com>
References: <qXonY64Tq0lRSrpqGH86L7qGC1lpTmNZtQk54HFbHG4=.08c6864e-b84b-48ff-90e3-4d0768b42c45@github.com>
 <lMfA2jjzowr6QCwVdCo5AwJf60Q-enozLDHhJ2VRJU0=.5536a2c3-d5fa-484a-925d-912ec496a77d@github.com>
Message-ID: <nyljxlXPLkhAgNss0bG10JZoGvd_Xotygm22Ss_pEUA=.65c20423-6197-42b3-9982-8a05e2a6e48d@github.com>

On Tue, 16 Apr 2024 06:08:58 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is the test issue. The `WaitingPT3` thread posted the `MonitorWait` event but has not released the `lockCheck` monitor yet. It has been fixed to wait for each `WaitingTask` thread to really reach the `WAITING` state. The same approach is used for `EnteringTask` threads. It has been fixed to wait for each `EnteringTask` thread to reach the `BLOCKED_ON_MONITOR` state.
>> 
>> Testing:
>>  - Reran the test `serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java` locally
>>  - TBD: submit the mach5 tiers 1-6 as well
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: removed event_lock; moved wait_for_state() to jvmti_common.hpp

Marked as reviewed by lmesnik (Reviewer).

The fix looks good, just one nit.
 rml.wait(100); might be changed to plain sleep(100)

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

PR Review: https://git.openjdk.org/jdk/pull/18778#pullrequestreview-2004437310
PR Comment: https://git.openjdk.org/jdk/pull/18778#issuecomment-2059776412

From kvn at openjdk.org  Tue Apr 16 19:24:03 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 16 Apr 2024 19:24:03 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v4]
In-Reply-To: <73tOotwsnkVfT0_0moY8U333EHAjV2MJ3amY6mMF58Y=.a5003aa6-4aea-4e20-82cc-0466403a9503@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
 <j3YYM1ZnxcYxXAio_cQ3c60_SyLpsFgsCQ-sekOfe_w=.16d895c8-93c0-4825-bedd-6aa701708743@github.com>
 <DDnSgwl-rv0d-9GXciIsijYY8g6nSs3bayg79Rl-H58=.13ed38c2-c7c7-44f9-81c8-db9cbcccbed7@github.com>
 <drVa2X5_UJ2H4Y36ZmC95IU5YN4wPs-uqxWDNcGjUy4=.01088b0f-94dc-47fb-bee6-2379d26d59f3@github.com>
 <73tOotwsnkVfT0_0moY8U333EHAjV2MJ3amY6mMF58Y=.a5003aa6-4aea-4e20-82cc-0466403a9503@github.com>
Message-ID: <TeD2kx8iSMTM7Le31okI3BkgFo92QEqF7wsTwQ022iA=.d71a0fde-fb81-46b2-b872-10cd7ec0cf87@github.com>

On Tue, 16 Apr 2024 19:03:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Thank you, @coleenp, foe looking on these changes.
>> 
>> Which fields are initialized twice? Only `_oop_maps` is set to `nullptr` before we proper build oop maps in first constructor.
>> 
>> The only saving could be lines of code but then I would have to check that `cb != nullptr` and do other additional checks which I don't think will save much lines.
>> 
>> Separation of `nmethod` constructor for native wrappers is helping clear see the difference and I would like to keep them separate. We have `init_defaults()` method for similar code and I can move more code into it from both constructors.
>
> Delegating constructors are the answer to having some common 'init' functions.  It would simply save lines of code that look the same in both constructor initializer lists.  But it's a drive-by comment.

Okay.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1567841490

From amenkov at openjdk.org  Tue Apr 16 19:48:06 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 16 Apr 2024 19:48:06 GMT
Subject: RFR: 8322043: HeapDumper should use parallel dump by default [v3]
In-Reply-To: <nm3Aa-QUDBK-uDHIjKrkqLRU2SuXYsOU3gA4NP1k7KE=.e3bb85e5-73ba-471e-9358-0ee6117edd15@github.com>
References: <m5p4qFndNtWAo_wwbdHKSJqG2XIcxwn_3tcJAYXAwgA=.dd4128e5-9688-45da-919e-683f4f6c6a10@github.com>
 <wYXpZGlcW9H9TuM_sosE7F1DTYGrxpsuiXn2QQDefmI=.a5b72739-9bf7-4624-aff1-59bf53bae5c8@github.com>
 <nm3Aa-QUDBK-uDHIjKrkqLRU2SuXYsOU3gA4NP1k7KE=.e3bb85e5-73ba-471e-9358-0ee6117edd15@github.com>
Message-ID: <iOtbKMYjxjBmooO1sZ64gXJjHqsbzg7AqwhkfVOX5Go=.f4614760-af8a-4dbd-8850-5b4d09a2ce38@github.com>

On Tue, 16 Apr 2024 09:08:20 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   check free_memory for OOME
>
> src/hotspot/share/services/heapDumper.hpp line 63:
> 
>> 61:   // additional info is written to out if not null.
>> 62:   // compression >= 0 creates a gzipped file with the given compression level.
>> 63:   // parallel_thread_num >= 0 indicates thread numbers of parallel object dump, -1 means "auto select".
> 
> I don't understand why you need to add `-1` to mean "auto-select" instead of just setting the default parameter to be `default_num_of_dump_threads()`?

I think it makes the code more flexible - it allows to distinguish between "use default value" and "I don't care" cases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18748#discussion_r1567864860

From kvn at openjdk.org  Tue Apr 16 19:50:01 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 16 Apr 2024 19:50:01 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v4]
In-Reply-To: <TeD2kx8iSMTM7Le31okI3BkgFo92QEqF7wsTwQ022iA=.d71a0fde-fb81-46b2-b872-10cd7ec0cf87@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
 <j3YYM1ZnxcYxXAio_cQ3c60_SyLpsFgsCQ-sekOfe_w=.16d895c8-93c0-4825-bedd-6aa701708743@github.com>
 <DDnSgwl-rv0d-9GXciIsijYY8g6nSs3bayg79Rl-H58=.13ed38c2-c7c7-44f9-81c8-db9cbcccbed7@github.com>
 <drVa2X5_UJ2H4Y36ZmC95IU5YN4wPs-uqxWDNcGjUy4=.01088b0f-94dc-47fb-bee6-2379d26d59f3@github.com>
 <73tOotwsnkVfT0_0moY8U333EHAjV2MJ3amY6mMF58Y=.a5003aa6-4aea-4e20-82cc-0466403a9503@github.com>
 <TeD2kx8iSMTM7Le31okI3BkgFo92QEqF7wsTwQ022iA=.d71a0fde-fb81-46b2-b872-10cd7ec0cf87@github.com>
Message-ID: <CU7PLbCMndxwN6HUGCb2msXqhHLh1vi0YWapTFvQebE=.b2cd6b57-59b2-44a0-a6d4-38365c0666e5@github.com>

On Tue, 16 Apr 2024 19:20:37 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Delegating constructors are the answer to having some common 'init' functions.  It would simply save lines of code that look the same in both constructor initializer lists.  But it's a drive-by comment.
>
> Okay.

It is tempting to do for `nmethod` to replace `init_defaults()`. I will look what can be done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1567866651

From kevinw at openjdk.org  Tue Apr 16 20:45:25 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 16 Apr 2024 20:45:25 GMT
Subject: RFR: 8318026: jcmd should provide access to detailed JVM object
 information [v16]
In-Reply-To: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
References: <5sy1bm5GDJQIWldrfcgjVyCDtLLkAsN8Cl0ziv_0XEQ=.88fbb771-85f4-4fa3-a228-479ece627ab0@github.com>
Message-ID: <jKEBQM4uN2TjtT1ihF8XuHPgUSsVLhnNCHPFBwtmSIE=.91d93168-90dd-4176-84f1-8de0adf14662@github.com>

> Introduce the jcmd "VM.inspect" to implement access to detailed JVM object information.
> 
> Not recommended for live production use.  Requires UnlockDiagnosticVMOptions and not included in jcmd help output, to remind us this is not a general-purpose customer-facing tool.

Kevin Walls 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 33 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into 8318026_jcmd_VMdebug_command
 - Update XX option
 - Update decode_raw usage to decode_without_asserts, after 8328698
 - nits
 - Merge remote-tracking branch 'upstream/master' into 8318026_jcmd_VMdebug_command
 - Update XX flag requirement
 - VMInspectTest update
 - Merge remote-tracking branch 'upstream/master' into 8318026_jcmd_VMdebug_command
 - One dbg_is_good_oop method
 - Test more pointer types: compiled method and metadata.
 - ... and 23 more: https://git.openjdk.org/jdk/compare/e5180fba...bb92a849

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17655/files
  - new: https://git.openjdk.org/jdk/pull/17655/files/7e6c7b97..bb92a849

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=17655&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17655&range=14-15

  Stats: 16719 lines in 562 files changed: 8816 ins; 4016 del; 3887 mod
  Patch: https://git.openjdk.org/jdk/pull/17655.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17655/head:pull/17655

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

From sspitsyn at openjdk.org  Tue Apr 16 21:30:59 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 16 Apr 2024 21:30:59 GMT
Subject: RFR: 8328741:
 serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java failed with
 unexpected owner [v2]
In-Reply-To: <nyljxlXPLkhAgNss0bG10JZoGvd_Xotygm22Ss_pEUA=.65c20423-6197-42b3-9982-8a05e2a6e48d@github.com>
References: <qXonY64Tq0lRSrpqGH86L7qGC1lpTmNZtQk54HFbHG4=.08c6864e-b84b-48ff-90e3-4d0768b42c45@github.com>
 <lMfA2jjzowr6QCwVdCo5AwJf60Q-enozLDHhJ2VRJU0=.5536a2c3-d5fa-484a-925d-912ec496a77d@github.com>
 <nyljxlXPLkhAgNss0bG10JZoGvd_Xotygm22Ss_pEUA=.65c20423-6197-42b3-9982-8a05e2a6e48d@github.com>
Message-ID: <8yRxfcPPGcwLa3SiH1l8a5MrnoXQTGJvAgDEpq80iz8=.1bbac9d4-fdb9-4403-9800-70258edb954e@github.com>

On Tue, 16 Apr 2024 19:21:16 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The fix looks good, just one nit. rml.wait(100); might be changed to plain sleep(100)

Right, thanks. Will fix it.

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

PR Comment: https://git.openjdk.org/jdk/pull/18778#issuecomment-2059950982

From sspitsyn at openjdk.org  Tue Apr 16 21:55:54 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 16 Apr 2024 21:55:54 GMT
Subject: RFR: 8328741:
 serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java failed with
 unexpected owner [v3]
In-Reply-To: <qXonY64Tq0lRSrpqGH86L7qGC1lpTmNZtQk54HFbHG4=.08c6864e-b84b-48ff-90e3-4d0768b42c45@github.com>
References: <qXonY64Tq0lRSrpqGH86L7qGC1lpTmNZtQk54HFbHG4=.08c6864e-b84b-48ff-90e3-4d0768b42c45@github.com>
Message-ID: <LC0kFo67F0FdPYb1naE2ixSoXlS08CusXzJYvO9tEKc=.1e79dd7b-8229-4c20-b56a-c3359b0dfe3d@github.com>

> This is the test issue. The `WaitingPT3` thread posted the `MonitorWait` event but has not released the `lockCheck` monitor yet. It has been fixed to wait for each `WaitingTask` thread to really reach the `WAITING` state. The same approach is used for `EnteringTask` threads. It has been fixed to wait for each `EnteringTask` thread to reach the `BLOCKED_ON_MONITOR` state.
> 
> Testing:
>  - Reran the test `serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java` locally
>  - TBD: submit the mach5 tiers 1-6 as well

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

  review: replaced wait with timeout with sleep_ms; fixed one test to use sleep_sec from test lib

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18778/files
  - new: https://git.openjdk.org/jdk/pull/18778/files/9941c492..68cdd8c7

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

  Stats: 9 lines in 2 files changed: 0 ins; 6 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18778.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18778/head:pull/18778

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

From kvn at openjdk.org  Tue Apr 16 22:15:02 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 16 Apr 2024 22:15:02 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v4]
In-Reply-To: <CU7PLbCMndxwN6HUGCb2msXqhHLh1vi0YWapTFvQebE=.b2cd6b57-59b2-44a0-a6d4-38365c0666e5@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
 <j3YYM1ZnxcYxXAio_cQ3c60_SyLpsFgsCQ-sekOfe_w=.16d895c8-93c0-4825-bedd-6aa701708743@github.com>
 <DDnSgwl-rv0d-9GXciIsijYY8g6nSs3bayg79Rl-H58=.13ed38c2-c7c7-44f9-81c8-db9cbcccbed7@github.com>
 <drVa2X5_UJ2H4Y36ZmC95IU5YN4wPs-uqxWDNcGjUy4=.01088b0f-94dc-47fb-bee6-2379d26d59f3@github.com>
 <73tOotwsnkVfT0_0moY8U333EHAjV2MJ3amY6mMF58Y=.a5003aa6-4aea-4e20-82cc-0466403a9503@github.com>
 <TeD2kx8iSMTM7Le31okI3BkgFo92QEqF7wsTwQ022iA=.d71a0fde-fb81-46b2-b872-10cd7ec0cf87@github.com>
 <CU7PLbCMndxwN6HUGCb2msXqhHLh1vi0YWapTFvQebE=.b2cd6b57-59b2-44a0-a6d4-38365c0666e5@github.com>
Message-ID: <6SY8mNq-z-vgrB2djgCc3mDTZpwniPi0lVy_sVULu84=.3882b3c9-80b8-4171-ae3d-a1f9d8261c6a@github.com>

On Tue, 16 Apr 2024 19:47:06 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Okay.
>
> It is tempting to do for `nmethod` to replace `init_defaults()`. I will look what can be done.

It does not work. It does not allow fields initialization after delegation:

src/hotspot/share/code/nmethod.cpp: In constructor 'nmethod::nmethod(Method*, CompilerType, int, int, CodeOffsets*, CodeBuffer*, int, ByteSize, ByteSize, OopMapSet*)':
src/hotspot/share/code/nmethod.cpp:1232:56: error: mem-initializer for 'nmethod::<unnamed union>::<unnamed struct>::_native_receiver_sp_offset' follows constructor delegation


Yes, I can move some fields initialization into body - but then it will be duplicated initialization.
>From reading net, the delegated constructor should take the largest number of arguments which default values are set by delegating constructors. It is not easy applicable to `nmethod` constructors - it will add more lines of code than remove. `nmethod` constructors we have are too big and different enough that delegation will not improve code.

I will keep `init_defaults()` and extend it to reduce common code in constructors.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1567992881

From sspitsyn at openjdk.org  Tue Apr 16 23:30:43 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 16 Apr 2024 23:30:43 GMT
Subject: RFR: 8328741:
 serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java failed with
 unexpected owner [v3]
In-Reply-To: <LC0kFo67F0FdPYb1naE2ixSoXlS08CusXzJYvO9tEKc=.1e79dd7b-8229-4c20-b56a-c3359b0dfe3d@github.com>
References: <qXonY64Tq0lRSrpqGH86L7qGC1lpTmNZtQk54HFbHG4=.08c6864e-b84b-48ff-90e3-4d0768b42c45@github.com>
 <LC0kFo67F0FdPYb1naE2ixSoXlS08CusXzJYvO9tEKc=.1e79dd7b-8229-4c20-b56a-c3359b0dfe3d@github.com>
Message-ID: <pMZtNt6y3qJWISNn-d9cbmHrUjXifbaist_hIfDLz0A=.f15592d9-aebf-401a-ae4d-7e984a657144@github.com>

On Tue, 16 Apr 2024 21:55:54 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is the test issue. The `WaitingPT3` thread posted the `MonitorWait` event but has not released the `lockCheck` monitor yet. It has been fixed to wait for each `WaitingTask` thread to really reach the `WAITING` state. The same approach is used for `EnteringTask` threads. It has been fixed to wait for each `EnteringTask` thread to reach the `BLOCKED_ON_MONITOR` state.
>> 
>> Testing:
>>  - Reran the test `serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java` locally
>>  - TBD: submit the mach5 tiers 1-6 as well
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: replaced wait with timeout with sleep_ms; fixed one test to use sleep_sec from test lib

Thank you for review, Leonid!

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

PR Comment: https://git.openjdk.org/jdk/pull/18778#issuecomment-2060066992

From sspitsyn at openjdk.org  Wed Apr 17 00:35:10 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 17 Apr 2024 00:35:10 GMT
Subject: RFR: 8330303: Crash: assert(_target_jt == nullptr ||
 _target_jt->vthread() == target_h()) failed
Message-ID: <s2XOP447huiEO4ph2kU-LkemkBxloUBcbcdtYOOnCpo=.98c07b6f-9e71-4e66-ac3d-7eab1c805dfc@github.com>

This is a simple fix of three similar asserts.
The `_target_jt->jvmti_vthread()` has to be used instead of `_target_jt->vthread()`. 
The `_target_jt->vthread()` can be outdated in some specific contexts as shown in the `hs_err` stack trace.

I've seen similar issue and already fixed it in this fragment of code:

class GetCurrentLocationClosure : public JvmtiUnitedHandshakeClosure {
  . . .
  void do_vthread(Handle target_h) {
    assert(_target_jt == nullptr || !_target_jt->is_exiting(), "sanity check");
    // use jvmti_vthread() as vthread() can be outdated
    assert(_target_jt == nullptr || _target_jt->jvmti_vthread() == target_h(), "sanity check");
    . . .

The issue above was fixed by replacing `_target_jt->vthread()` with `_target_jt->jvmti_vthread()`.

There are three places which need to be fixed the same way:
 - `GetSingleStackTraceClosure::do_vthread(Handle target_h)`
 - `SetForceEarlyReturn::do_vthread(Handle target_h)`
 - `UpdateForPopTopFrameClosure::do_vthread(Handle target_h)`

Testing:
 - Run mach5 tiers 1-6

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

Commit messages:
 - add comments explaining that the vthread() can return outdated oop
 - 8330303: Crash: assert(_target_jt == nullptr || _target_jt->vthread() == target_h()) failed

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

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

From kvn at openjdk.org  Wed Apr 17 00:56:33 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 17 Apr 2024 00:56:33 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v6]
In-Reply-To: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
Message-ID: <qeQPKHeu0EGye_iY6z6HglVZysC4kCwGg6BA7_6Nn_A=.0a79fc18-e54e-4193-92f9-cc9f4423a82b@github.com>

> This is part of changes which try to reduce size of `nmethod` and `codeblob` data vs code in CodeCache.
> These changes reduced size of `nmethod` header from 288 to 232 bytes. From 304 to 248 in optimized VM:
> 
> Statistics for 1282 bytecoded nmethods for C2:
>  total in heap = 5560352 (100%)
>  header = 389728 (7.009053%)
> 
> vs
> 
> Statistics for 1322 bytecoded nmethods for C2:
>  total in heap  = 8307120 (100%)
>  header         = 327856 (3.946687%)
> 
> 
> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some fields were changed from `int` to `int16_t` with added corresponding asserts to make sure their values are fit into 16 bits.
> 
> I did additional cleanup after recent `CompiledMethod` removal.
> 
> Tested tier1-7,stress,xcomp and performance testing.

Vladimir Kozlov has updated the pull request incrementally with two additional commits since the last revision:

 - remove trailing space
 - Shuffle fields initialization

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18768/files
  - new: https://git.openjdk.org/jdk/pull/18768/files/8405a23d..6a164b11

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

  Stats: 158 lines in 3 files changed: 73 ins; 75 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/18768.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18768/head:pull/18768

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

From jkratochvil at openjdk.org  Wed Apr 17 01:09:46 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Wed, 17 Apr 2024 01:09:46 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v2]
In-Reply-To: <XpaCLyqit2xsq95Sou7z9clG7WWTwzIBR16ib0_xlDc=.376b07f0-3efd-4c85-a9c5-a61a4bdc0d61@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <trUwK5rQzvQtPnGLg7PeAvOdtPfJHFpEKdtyJcLj6Bw=.2435ad46-f513-4f20-952d-70c1b1f24924@github.com>
 <E0c7XjQsTAjQ3oBR-9IrqKS-o6eaMrhYx2WxiRPEFJM=.af4c068c-e43e-460d-9b45-256df9205b28@github.com>
 <XpaCLyqit2xsq95Sou7z9clG7WWTwzIBR16ib0_xlDc=.376b07f0-3efd-4c85-a9c5-a61a4bdc0d61@github.com>
Message-ID: <AyhwTYv3k8rFJ2k4nQT93fwyO_1gXMALMmmckLwrfpw=.2994f76e-ca36-4013-b03b-d4006349ad38@github.com>

On Tue, 16 Apr 2024 15:17:33 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> The idea here is to use this property to tune OpenJDK for in-container, specifically k8s, use. In such a setup it's custom to run a single process within set resource constraints.

The in-container tuning means to use all the available resources. Containers in the real world have some memory limits set which is where my modified patch still correctly identifies it as a container to use all the available resources of the node which is the whole goal of the container detection code.

> In order to do this, we need a reliable way to distinguish that vs. non-containerized setup.

I expect it should have been written "We need a reliable way to distinguish real world in-container vs. non-containerized setup. We do not mind behavior for artificial containers on OpenJDK development machines.". Which is what my patch does in an easier and less error-prone way.

> If somebody really wants to run OpenJDK in a container expecting it to run like a physical OpenJDK deployment, that's when `-XX:-UseContainerSupport` should be used.

That behaves still the same with my patch.

Could you give a countercase where my patch behaves wrongly?

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

PR Comment: https://git.openjdk.org/jdk/pull/18201#issuecomment-2060158409

From dholmes at openjdk.org  Wed Apr 17 07:26:00 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 17 Apr 2024 07:26:00 GMT
Subject: RFR: 8322043: HeapDumper should use parallel dump by default [v3]
In-Reply-To: <iOtbKMYjxjBmooO1sZ64gXJjHqsbzg7AqwhkfVOX5Go=.f4614760-af8a-4dbd-8850-5b4d09a2ce38@github.com>
References: <m5p4qFndNtWAo_wwbdHKSJqG2XIcxwn_3tcJAYXAwgA=.dd4128e5-9688-45da-919e-683f4f6c6a10@github.com>
 <wYXpZGlcW9H9TuM_sosE7F1DTYGrxpsuiXn2QQDefmI=.a5b72739-9bf7-4624-aff1-59bf53bae5c8@github.com>
 <nm3Aa-QUDBK-uDHIjKrkqLRU2SuXYsOU3gA4NP1k7KE=.e3bb85e5-73ba-471e-9358-0ee6117edd15@github.com>
 <iOtbKMYjxjBmooO1sZ64gXJjHqsbzg7AqwhkfVOX5Go=.f4614760-af8a-4dbd-8850-5b4d09a2ce38@github.com>
Message-ID: <91Txr1a0tZ_40Rr5yO4H0qBNdyOWFrreV48Blk_v_bA=.427ce8b7-7953-49d6-b961-cac6dbc4e963@github.com>

On Tue, 16 Apr 2024 19:45:12 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> src/hotspot/share/services/heapDumper.hpp line 63:
>> 
>>> 61:   // additional info is written to out if not null.
>>> 62:   // compression >= 0 creates a gzipped file with the given compression level.
>>> 63:   // parallel_thread_num >= 0 indicates thread numbers of parallel object dump, -1 means "auto select".
>> 
>> I don't understand why you need to add `-1` to mean "auto-select" instead of just setting the default parameter to be `default_num_of_dump_threads()`?
>
> I think it makes the code more flexible - it allows to distinguish between "use default value" and "I don't care" cases.

I'm not sure it is a worthwhile distinction. Not passing an actual parameter means "I don't care - take the default".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18748#discussion_r1568350751

From stuefe at openjdk.org  Wed Apr 17 13:22:03 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 17 Apr 2024 13:22:03 GMT
Subject: RFR: 8322043: HeapDumper should use parallel dump by default [v3]
In-Reply-To: <91Txr1a0tZ_40Rr5yO4H0qBNdyOWFrreV48Blk_v_bA=.427ce8b7-7953-49d6-b961-cac6dbc4e963@github.com>
References: <m5p4qFndNtWAo_wwbdHKSJqG2XIcxwn_3tcJAYXAwgA=.dd4128e5-9688-45da-919e-683f4f6c6a10@github.com>
 <wYXpZGlcW9H9TuM_sosE7F1DTYGrxpsuiXn2QQDefmI=.a5b72739-9bf7-4624-aff1-59bf53bae5c8@github.com>
 <nm3Aa-QUDBK-uDHIjKrkqLRU2SuXYsOU3gA4NP1k7KE=.e3bb85e5-73ba-471e-9358-0ee6117edd15@github.com>
 <iOtbKMYjxjBmooO1sZ64gXJjHqsbzg7AqwhkfVOX5Go=.f4614760-af8a-4dbd-8850-5b4d09a2ce38@github.com>
 <91Txr1a0tZ_40Rr5yO4H0qBNdyOWFrreV48Blk_v_bA=.427ce8b7-7953-49d6-b961-cac6dbc4e963@github.com>
Message-ID: <cmkC378i4sihJ0MMaubon99etD7vt5nwDBJQ6b7TxHs=.a7d31fc0-a51c-4c67-af4e-1a61542fab0a@github.com>

On Wed, 17 Apr 2024 07:22:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I think it makes the code more flexible - it allows to distinguish between "use default value" and "I don't care" cases.
>
> I'm not sure it is a worthwhile distinction. Not passing an actual parameter means "I don't care - take the default".

I agree with @dholmes-ora. Let's keep things simple.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18748#discussion_r1568833440

From cslucas at openjdk.org  Wed Apr 17 17:19:01 2024
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 17 Apr 2024 17:19:01 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v6]
In-Reply-To: <qeQPKHeu0EGye_iY6z6HglVZysC4kCwGg6BA7_6Nn_A=.0a79fc18-e54e-4193-92f9-cc9f4423a82b@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
 <qeQPKHeu0EGye_iY6z6HglVZysC4kCwGg6BA7_6Nn_A=.0a79fc18-e54e-4193-92f9-cc9f4423a82b@github.com>
Message-ID: <qZJ96PofOCDDZBaee9V17pkcIeneipRAmC6hHJnedV0=.f02403ac-6498-4c2f-8574-4237d0ad58ad@github.com>

On Wed, 17 Apr 2024 00:56:33 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> This is part of changes which try to reduce size of `nmethod` and `codeblob` data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From 304 to 248 in optimized VM:
>> 
>> Statistics for 1282 bytecoded nmethods for C2:
>>  total in heap = 5560352 (100%)
>>  header = 389728 (7.009053%)
>> 
>> vs
>> 
>> Statistics for 1322 bytecoded nmethods for C2:
>>  total in heap  = 8307120 (100%)
>>  header         = 327856 (3.946687%)
>> 
>> 
>> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some fields were changed from `int` to `int16_t` with added corresponding asserts to make sure their values are fit into 16 bits.
>> 
>> I did additional cleanup after recent `CompiledMethod` removal.
>> 
>> Tested tier1-7,stress,xcomp and performance testing.
>
> Vladimir Kozlov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove trailing space
>  - Shuffle fields initialization

src/hotspot/share/code/nmethod.hpp line 259:

> 257:   int _orig_pc_offset;
> 258: 
> 259:   int          _compile_id;            // which compilation made this nmethod

NIT: are these fields always needed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1569185473

From kvn at openjdk.org  Wed Apr 17 17:53:08 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 17 Apr 2024 17:53:08 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v6]
In-Reply-To: <qZJ96PofOCDDZBaee9V17pkcIeneipRAmC6hHJnedV0=.f02403ac-6498-4c2f-8574-4237d0ad58ad@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
 <qeQPKHeu0EGye_iY6z6HglVZysC4kCwGg6BA7_6Nn_A=.0a79fc18-e54e-4193-92f9-cc9f4423a82b@github.com>
 <qZJ96PofOCDDZBaee9V17pkcIeneipRAmC6hHJnedV0=.f02403ac-6498-4c2f-8574-4237d0ad58ad@github.com>
Message-ID: <9FJAaJ67TpV0_rGDkLEmyJf3I3K7yF61rapAIg6Znrk=.fbd4cb50-833e-4588-8463-69d2c38fb48e@github.com>

On Wed, 17 Apr 2024 17:10:50 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - remove trailing space
>>  - Shuffle fields initialization
>
> src/hotspot/share/code/nmethod.hpp line 259:
> 
>> 257:   int _orig_pc_offset;
>> 258: 
>> 259:   int          _compile_id;            // which compilation made this nmethod
> 
> NIT: are these fields always needed?

Yes, they are needed for debugging issues. They are important for error reporting, logs and events recording.  And they do not take much space: CompLevel and CompilerType are one byte size.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1569237659

From matsaave at openjdk.org  Wed Apr 17 18:53:25 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 17 Apr 2024 18:53:25 GMT
Subject: RFR: 8330388: Remove invokedynamic cache index encoding
Message-ID: <QbD7B30aa0z4LsbSTZbxGQVFUu5yxpCFiiNZTdskonY=.eaca60d3-73fc-4302-8aa0-c06e5b855cfd@github.com>

Before [JDK-8307190](https://bugs.openjdk.org/browse/JDK-8307190), [JDK-8309673](https://bugs.openjdk.org/browse/JDK-8309673), and [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995), invokedynamic operands needed to be rewritten to encoded values to better distinguish indy entries from other cp cache entries. The above changes now distinguish between entries with `to_cp_index()` using the bytecode, which is now propagated by the callers.

The encoding flips the bits of the index so the encoded index is always negative, leading to access errors if there is no matching decode call. These calls are removed with some methods adjusted to distinguish between indices with the bytecode. Verified with tier 1-5 tests.

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

Commit messages:
 - 8330388: Remove invokedynamic cache index encoding

Changes: https://git.openjdk.org/jdk/pull/18819/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18819&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330388
  Stats: 220 lines in 37 files changed: 15 ins; 136 del; 69 mod
  Patch: https://git.openjdk.org/jdk/pull/18819.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18819/head:pull/18819

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

From lmesnik at openjdk.org  Wed Apr 17 20:03:59 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 17 Apr 2024 20:03:59 GMT
Subject: RFR: 8328741:
 serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java failed with
 unexpected owner [v3]
In-Reply-To: <LC0kFo67F0FdPYb1naE2ixSoXlS08CusXzJYvO9tEKc=.1e79dd7b-8229-4c20-b56a-c3359b0dfe3d@github.com>
References: <qXonY64Tq0lRSrpqGH86L7qGC1lpTmNZtQk54HFbHG4=.08c6864e-b84b-48ff-90e3-4d0768b42c45@github.com>
 <LC0kFo67F0FdPYb1naE2ixSoXlS08CusXzJYvO9tEKc=.1e79dd7b-8229-4c20-b56a-c3359b0dfe3d@github.com>
Message-ID: <L5yq49zOIaRirZBOWf8IoIztzuAMu52V_RkLXcg5y_E=.a303685a-4eef-41ba-bfa9-b881996e92fa@github.com>

On Tue, 16 Apr 2024 21:55:54 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is the test issue. The `WaitingPT3` thread posted the `MonitorWait` event but has not released the `lockCheck` monitor yet. It has been fixed to wait for each `WaitingTask` thread to really reach the `WAITING` state. The same approach is used for `EnteringTask` threads. It has been fixed to wait for each `EnteringTask` thread to reach the `BLOCKED_ON_MONITOR` state.
>> 
>> Testing:
>>  - Reran the test `serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java` locally
>>  - TBD: submit the mach5 tiers 1-6 as well
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: replaced wait with timeout with sleep_ms; fixed one test to use sleep_sec from test lib

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18778#pullrequestreview-2007023177

From lmesnik at openjdk.org  Wed Apr 17 20:25:15 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 17 Apr 2024 20:25:15 GMT
Subject: RFR: 8330534: Update nsk/jdwp tests to use driver instead of othervm
Message-ID: <-E7U6V_sADPCLdV_Gj37G-0glwUswNfxNyNw43jz120=.436faccd-f4ef-4209-b550-74a04b413ad2@github.com>

The jdwp tests use debugger and debugee. There is no goal to execute debugger part with all VM flags, they are needed to be used with debugee VM only.
The change is all tests is to don't use System.exit() and use 'driver' instead of othervm.
test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeBinder.java
is updated to correctly set classpath for debugee

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

Commit messages:
 - 8330534: Update nsk/jdwp tests to use driver instead of othervm

Changes: https://git.openjdk.org/jdk/pull/18826/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18826&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330534
  Stats: 824 lines in 219 files changed: 342 ins; 0 del; 482 mod
  Patch: https://git.openjdk.org/jdk/pull/18826.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18826/head:pull/18826

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

From dlong at openjdk.org  Wed Apr 17 20:31:03 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 17 Apr 2024 20:31:03 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v3]
In-Reply-To: <YsJ6qXdQorENXip_NL4kFVBhoJc5unYiTR1E4B5TSJ8=.acfda678-11a5-4ce4-9982-5a8114edd34c@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
 <jMqrswByOAiVWG4wYedLPtkftNhDdLJqbzyTpF1N2DE=.26ae646c-4bbb-4ef7-91d7-0adb401fb809@github.com>
 <EOhsDK7-ekMevDMMaB6B27pU4yajQHbiESSc9vCnui0=.01db9c3e-1214-4655-8f70-815c65056b19@github.com>
 <YsJ6qXdQorENXip_NL4kFVBhoJc5unYiTR1E4B5TSJ8=.acfda678-11a5-4ce4-9982-5a8114edd34c@github.com>
Message-ID: <wPS3kFeKkD3KWGH6P2p8h4Ur_YXITpJiWOqK8gdXprA=.8e85caac-494a-4ec5-910d-7123fe94f396@github.com>

On Tue, 16 Apr 2024 16:09:21 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> src/hotspot/share/code/nmethod.cpp line 1441:
>> 
>>> 1439:     int deps_size     = align_up((int)dependencies->size_in_bytes(), oopSize);
>>> 1440:     int sum_size      = oops_size + metadata_size + deps_size;
>>> 1441:     assert((sum_size >> 16) == 0, "data size is bigger than 64Kb: %d", sum_size);
>> 
>> I suggest using checked_cast for the assignment below, rather than special-purpose checks here.
>
> Okay. But I will put above code under `#ifdef ASSERT` then.

The ASSERT block above looks unnecessary, now that field assignments below are using checked_cast.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1569496753

From amenkov at openjdk.org  Wed Apr 17 20:38:25 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 17 Apr 2024 20:38:25 GMT
Subject: RFR: 8322043: HeapDumper should use parallel dump by default [v4]
In-Reply-To: <m5p4qFndNtWAo_wwbdHKSJqG2XIcxwn_3tcJAYXAwgA=.dd4128e5-9688-45da-919e-683f4f6c6a10@github.com>
References: <m5p4qFndNtWAo_wwbdHKSJqG2XIcxwn_3tcJAYXAwgA=.dd4128e5-9688-45da-919e-683f4f6c6a10@github.com>
Message-ID: <SuKc_j1T-EE5Tpt_bumtbFpizKCb6mA1HKRbxp-SusA=.fd1177fc-7be4-4a29-9028-201061c79e17@github.com>

> The fix makes VM heap dumping parallel by default.
> `jcmd GC.heap_dump` and `jmap -dump` had parallel dumping by default, the fix affects `HotSpotDiagnosticMXBean.dumpHeap()`, `-XX:+HeapDumpBeforeFullGC`, `-XX:+HeapDumpAfterFullGC` and `-XX:+HeapDumpOnOutOfMemoryError`.
> 
> Testing:
>   - manually tested different heap dump scenarios with `-Xlog:heapdump`;
>   - tier1,tier2,hs-tier5-svc;
>   - all reg.tests that use heap dump.

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18748/files
  - new: https://git.openjdk.org/jdk/pull/18748/files/f6db604f..482d9ffe

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

  Stats: 18 lines in 3 files changed: 0 ins; 3 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/18748.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18748/head:pull/18748

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

From amenkov at openjdk.org  Wed Apr 17 20:42:54 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 17 Apr 2024 20:42:54 GMT
Subject: RFR: 8322043: HeapDumper should use parallel dump by default [v5]
In-Reply-To: <m5p4qFndNtWAo_wwbdHKSJqG2XIcxwn_3tcJAYXAwgA=.dd4128e5-9688-45da-919e-683f4f6c6a10@github.com>
References: <m5p4qFndNtWAo_wwbdHKSJqG2XIcxwn_3tcJAYXAwgA=.dd4128e5-9688-45da-919e-683f4f6c6a10@github.com>
Message-ID: <mxfsfJYeBPTzpL8ttJwLDSb_unfUg-ta444F_HcF7LI=.d2176032-6af9-4249-99ae-3c1ed18188d9@github.com>

> The fix makes VM heap dumping parallel by default.
> `jcmd GC.heap_dump` and `jmap -dump` had parallel dumping by default, the fix affects `HotSpotDiagnosticMXBean.dumpHeap()`, `-XX:+HeapDumpBeforeFullGC`, `-XX:+HeapDumpAfterFullGC` and `-XX:+HeapDumpOnOutOfMemoryError`.
> 
> Testing:
>   - manually tested different heap dump scenarios with `-Xlog:heapdump`;
>   - tier1,tier2,hs-tier5-svc;
>   - all reg.tests that use heap dump.

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  removed unneeded cast

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18748/files
  - new: https://git.openjdk.org/jdk/pull/18748/files/482d9ffe..641bedc5

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

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

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

From cjplummer at openjdk.org  Wed Apr 17 21:16:11 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 17 Apr 2024 21:16:11 GMT
Subject: RFR: 8330388: Remove invokedynamic cache index encoding
In-Reply-To: <QbD7B30aa0z4LsbSTZbxGQVFUu5yxpCFiiNZTdskonY=.eaca60d3-73fc-4302-8aa0-c06e5b855cfd@github.com>
References: <QbD7B30aa0z4LsbSTZbxGQVFUu5yxpCFiiNZTdskonY=.eaca60d3-73fc-4302-8aa0-c06e5b855cfd@github.com>
Message-ID: <fHpKcVvgcspZ98zufW-hOJdAF7VJRazlkY7vJJ-O4Sw=.34bf27c3-d897-4b6d-8c0f-a1fcafae1f09@github.com>

On Wed, 17 Apr 2024 15:26:52 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> Before [JDK-8307190](https://bugs.openjdk.org/browse/JDK-8307190), [JDK-8309673](https://bugs.openjdk.org/browse/JDK-8309673), and [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995), invokedynamic operands needed to be rewritten to encoded values to better distinguish indy entries from other cp cache entries. The above changes now distinguish between entries with `to_cp_index()` using the bytecode, which is now propagated by the callers.
> 
> The encoding flips the bits of the index so the encoded index is always negative, leading to access errors if there is no matching decode call. These calls are removed with some methods adjusted to distinguish between indices with the bytecode. Verified with tier 1-5 tests.

SA changes look good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18819#pullrequestreview-2007176260

From kvn at openjdk.org  Wed Apr 17 21:16:48 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 17 Apr 2024 21:16:48 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v3]
In-Reply-To: <wPS3kFeKkD3KWGH6P2p8h4Ur_YXITpJiWOqK8gdXprA=.8e85caac-494a-4ec5-910d-7123fe94f396@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
 <jMqrswByOAiVWG4wYedLPtkftNhDdLJqbzyTpF1N2DE=.26ae646c-4bbb-4ef7-91d7-0adb401fb809@github.com>
 <EOhsDK7-ekMevDMMaB6B27pU4yajQHbiESSc9vCnui0=.01db9c3e-1214-4655-8f70-815c65056b19@github.com>
 <YsJ6qXdQorENXip_NL4kFVBhoJc5unYiTR1E4B5TSJ8=.acfda678-11a5-4ce4-9982-5a8114edd34c@github.com>
 <wPS3kFeKkD3KWGH6P2p8h4Ur_YXITpJiWOqK8gdXprA=.8e85caac-494a-4ec5-910d-7123fe94f396@github.com>
Message-ID: <MkqIjZeD1pgaH393jHuAa9Slpm6JPhpnPvT7wWLpVPI=.e7f1a60f-f834-40bc-acc0-ba3b12f9c242@github.com>

On Wed, 17 Apr 2024 20:27:53 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Okay. But I will put above code under `#ifdef ASSERT` then.
>
> The ASSERT block above looks unnecessary, now that field assignments below are using checked_cast.

Agree, but I need to change how I use checked_cast below to get the same check as above. I will do it in next update:

 _dependencies_offset  = _metadata_offset      + checked_cast<uint16_t>(align_up(code_buffer->total_metadata_size(), wordSize));
 _scopes_pcs_offset    = _dependencies_offset  + checked_cast<uint16_t>(align_up((int)dependencies->size_in_bytes(), oopSize));
---
 _dependencies_offset  = checked_cast<uint16_t>(_metadata_offset + align_up(code_buffer->total_metadata_size(), wordSize));
 _scopes_pcs_offset    = checked_cast<uint16_t>(_dependencies_offset  + align_up((int)dependencies->size_in_bytes(), oopSize));

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18768#discussion_r1569563003

From kvn at openjdk.org  Wed Apr 17 22:23:47 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 17 Apr 2024 22:23:47 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v7]
In-Reply-To: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
Message-ID: <brKHljXDubyXR7afU-cv08DKiIyH0Y0P4HYPUVlTDHI=.f21bfc19-3e47-428b-ad3e-47ed3db165bb@github.com>

> This is part of changes which try to reduce size of `nmethod` and `codeblob` data vs code in CodeCache.
> These changes reduced size of `nmethod` header from 288 to 232 bytes. From 304 to 248 in optimized VM:
> 
> Statistics for 1282 bytecoded nmethods for C2:
>  total in heap = 5560352 (100%)
>  header = 389728 (7.009053%)
> 
> vs
> 
> Statistics for 1322 bytecoded nmethods for C2:
>  total in heap  = 8307120 (100%)
>  header         = 327856 (3.946687%)
> 
> 
> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some fields were changed from `int` to `int16_t` with added corresponding asserts to make sure their values are fit into 16 bits.
> 
> I did additional cleanup after recent `CompiledMethod` removal.
> 
> Tested tier1-7,stress,xcomp and performance testing.

Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge master
 - remove trailing space
 - Shuffle fields initialization
 - Address comments. Used checked_cast.
 - Use 16-bits types for header_size and frame_complete_offset arguments
 - Union fields which usages do not overlap
 - Moved some fields initialization into init_defaults()
 - 8329433: Reduce nmethod header size

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

Changes: https://git.openjdk.org/jdk/pull/18768/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18768&range=06
  Stats: 528 lines in 15 files changed: 140 ins; 178 del; 210 mod
  Patch: https://git.openjdk.org/jdk/pull/18768.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18768/head:pull/18768

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

From dlong at openjdk.org  Wed Apr 17 22:47:56 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 17 Apr 2024 22:47:56 GMT
Subject: RFR: 8330388: Remove invokedynamic cache index encoding
In-Reply-To: <QbD7B30aa0z4LsbSTZbxGQVFUu5yxpCFiiNZTdskonY=.eaca60d3-73fc-4302-8aa0-c06e5b855cfd@github.com>
References: <QbD7B30aa0z4LsbSTZbxGQVFUu5yxpCFiiNZTdskonY=.eaca60d3-73fc-4302-8aa0-c06e5b855cfd@github.com>
Message-ID: <ENt3LP5_1w0ffj8dGmobLgcZxXt_LxGCTvTwGbQLJic=.b680a61f-7cb8-4a34-a42a-be8120f5f7b1@github.com>

On Wed, 17 Apr 2024 15:26:52 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> Before [JDK-8307190](https://bugs.openjdk.org/browse/JDK-8307190), [JDK-8309673](https://bugs.openjdk.org/browse/JDK-8309673), and [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995), invokedynamic operands needed to be rewritten to encoded values to better distinguish indy entries from other cp cache entries. The above changes now distinguish between entries with `to_cp_index()` using the bytecode, which is now propagated by the callers.
> 
> The encoding flips the bits of the index so the encoded index is always negative, leading to access errors if there is no matching decode call. These calls are removed with some methods adjusted to distinguish between indices with the bytecode. Verified with tier 1-5 tests.

src/hotspot/share/ci/ciEnv.cpp line 1513:

> 1511:     // process the BSM
> 1512:     int pool_index = indy_info->constant_pool_index();
> 1513:     BootstrapInfo bootstrap_specifier(cp, pool_index, indy_index);

Why not just change the incoming parameter name to `index`?

src/hotspot/share/classfile/resolutionErrors.hpp line 60:

> 58: 
> 59:   // This function is used to encode an invokedynamic index to differentiate it from a
> 60:   // constant pool index.  It assumes it is being called with a index that is less than 0

Is this comment still correct?

src/hotspot/share/interpreter/bootstrapInfo.cpp line 77:

> 75:     return true;
> 76:   } else if (indy_entry->resolution_failed()) {
> 77:     int encoded_index = ResolutionErrorTable::encode_indy_index(_indy_index);

That's an improvement, from two levels of encoding to only one!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18819#discussion_r1569625123
PR Review Comment: https://git.openjdk.org/jdk/pull/18819#discussion_r1569626519
PR Review Comment: https://git.openjdk.org/jdk/pull/18819#discussion_r1569627219

From dlong at openjdk.org  Wed Apr 17 22:51:07 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 17 Apr 2024 22:51:07 GMT
Subject: RFR: 8330388: Remove invokedynamic cache index encoding
In-Reply-To: <QbD7B30aa0z4LsbSTZbxGQVFUu5yxpCFiiNZTdskonY=.eaca60d3-73fc-4302-8aa0-c06e5b855cfd@github.com>
References: <QbD7B30aa0z4LsbSTZbxGQVFUu5yxpCFiiNZTdskonY=.eaca60d3-73fc-4302-8aa0-c06e5b855cfd@github.com>
Message-ID: <-5i_BDguO1qWOP0GnYK4pTeMMW4IhlV3LkqLPFs4vAw=.060c849a-de1a-4888-943e-80b9ed4eecf2@github.com>

On Wed, 17 Apr 2024 15:26:52 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> Before [JDK-8307190](https://bugs.openjdk.org/browse/JDK-8307190), [JDK-8309673](https://bugs.openjdk.org/browse/JDK-8309673), and [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995), invokedynamic operands needed to be rewritten to encoded values to better distinguish indy entries from other cp cache entries. The above changes now distinguish between entries with `to_cp_index()` using the bytecode, which is now propagated by the callers.
> 
> The encoding flips the bits of the index so the encoded index is always negative, leading to access errors if there is no matching decode call. These calls are removed with some methods adjusted to distinguish between indices with the bytecode. Verified with tier 1-5 tests.

Did you consider minimizing changes by leaving decode_invokedynamic_index/encode_invokedynamic_index calls in place, but having the implementations not change the value?

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

PR Comment: https://git.openjdk.org/jdk/pull/18819#issuecomment-2062609288

From dlong at openjdk.org  Wed Apr 17 23:00:56 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 17 Apr 2024 23:00:56 GMT
Subject: RFR: 8330388: Remove invokedynamic cache index encoding
In-Reply-To: <QbD7B30aa0z4LsbSTZbxGQVFUu5yxpCFiiNZTdskonY=.eaca60d3-73fc-4302-8aa0-c06e5b855cfd@github.com>
References: <QbD7B30aa0z4LsbSTZbxGQVFUu5yxpCFiiNZTdskonY=.eaca60d3-73fc-4302-8aa0-c06e5b855cfd@github.com>
Message-ID: <JQESdDCAbijnaCyub9f3AK1rXr9JzamIexYhPywvVDM=.f84c1110-938d-4fdb-9abb-17326bd610ad@github.com>

On Wed, 17 Apr 2024 15:26:52 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> Before [JDK-8307190](https://bugs.openjdk.org/browse/JDK-8307190), [JDK-8309673](https://bugs.openjdk.org/browse/JDK-8309673), and [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995), invokedynamic operands needed to be rewritten to encoded values to better distinguish indy entries from other cp cache entries. The above changes now distinguish between entries with `to_cp_index()` using the bytecode, which is now propagated by the callers.
> 
> The encoding flips the bits of the index so the encoded index is always negative, leading to access errors if there is no matching decode call. These calls are removed with some methods adjusted to distinguish between indices with the bytecode. Verified with tier 1-5 tests.

@dougxc should check JVMCI changes.

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

Marked as reviewed by dlong (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18819#pullrequestreview-2007498087

From kvn at openjdk.org  Thu Apr 18 00:41:03 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 18 Apr 2024 00:41:03 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v8]
In-Reply-To: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
Message-ID: <dgiye_PwnS18gvpQqDERagHD293R_D0iwcTDNjrtgL8=.c803bb0d-abc5-4a58-a8a5-3ef396c349b4@github.com>

> This is part of changes which try to reduce size of `nmethod` and `codeblob` data vs code in CodeCache.
> These changes reduced size of `nmethod` header from 288 to 232 bytes. From 304 to 248 in optimized VM:
> 
> Statistics for 1282 bytecoded nmethods for C2:
>  total in heap = 5560352 (100%)
>  header = 389728 (7.009053%)
> 
> vs
> 
> Statistics for 1322 bytecoded nmethods for C2:
>  total in heap  = 8307120 (100%)
>  header         = 327856 (3.946687%)
> 
> 
> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some fields were changed from `int` to `int16_t` with added corresponding asserts to make sure their values are fit into 16 bits.
> 
> I did additional cleanup after recent `CompiledMethod` removal.
> 
> Tested tier1-7,stress,xcomp and performance testing.

Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  Address comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18768/files
  - new: https://git.openjdk.org/jdk/pull/18768/files/adc17594..5f5f30de

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

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

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

From kvn at openjdk.org  Thu Apr 18 00:41:05 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 18 Apr 2024 00:41:05 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v7]
In-Reply-To: <brKHljXDubyXR7afU-cv08DKiIyH0Y0P4HYPUVlTDHI=.f21bfc19-3e47-428b-ad3e-47ed3db165bb@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
 <brKHljXDubyXR7afU-cv08DKiIyH0Y0P4HYPUVlTDHI=.f21bfc19-3e47-428b-ad3e-47ed3db165bb@github.com>
Message-ID: <DqYfax4_VIXTayiLsGf2CNKEA3e2v4rP2AJEnKXGcz8=.a19e2ac3-4d5f-4d61-9095-610e0d4bcd9d@github.com>

On Wed, 17 Apr 2024 22:23:47 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> This is part of changes which try to reduce size of `nmethod` and `codeblob` data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From 304 to 248 in optimized VM:
>> 
>> Statistics for 1282 bytecoded nmethods for C2:
>>  total in heap = 5560352 (100%)
>>  header = 389728 (7.009053%)
>> 
>> vs
>> 
>> Statistics for 1322 bytecoded nmethods for C2:
>>  total in heap  = 8307120 (100%)
>>  header         = 327856 (3.946687%)
>> 
>> 
>> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some fields were changed from `int` to `int16_t` with added corresponding asserts to make sure their values are fit into 16 bits.
>> 
>> I did additional cleanup after recent `CompiledMethod` removal.
>> 
>> Tested tier1-7,stress,xcomp and performance testing.
>
> Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge master
>  - remove trailing space
>  - Shuffle fields initialization
>  - Address comments. Used checked_cast.
>  - Use 16-bits types for header_size and frame_complete_offset arguments
>  - Union fields which usages do not overlap
>  - Moved some fields initialization into init_defaults()
>  - 8329433: Reduce nmethod header size

Merge [#18637](https://github.com/openjdk/jdk/pull/18637) added an other `short` field `_num_stack_arg_slots` which pushed `nmethod` size back to 240 bytes in product VM. I will not do changes in **this** PR to compensate it.

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

PR Comment: https://git.openjdk.org/jdk/pull/18768#issuecomment-2062779812

From kvn at openjdk.org  Thu Apr 18 00:43:00 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 18 Apr 2024 00:43:00 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v7]
In-Reply-To: <brKHljXDubyXR7afU-cv08DKiIyH0Y0P4HYPUVlTDHI=.f21bfc19-3e47-428b-ad3e-47ed3db165bb@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
 <brKHljXDubyXR7afU-cv08DKiIyH0Y0P4HYPUVlTDHI=.f21bfc19-3e47-428b-ad3e-47ed3db165bb@github.com>
Message-ID: <yXhVV4trcO6shWVub1FylQBRUheihwgkTLRZTjQW9CM=.06c260bb-5491-4f0a-8668-5c9c37428845@github.com>

On Wed, 17 Apr 2024 22:23:47 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> This is part of changes which try to reduce size of `nmethod` and `codeblob` data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From 304 to 248 in optimized VM:
>> 
>> Statistics for 1282 bytecoded nmethods for C2:
>>  total in heap = 5560352 (100%)
>>  header = 389728 (7.009053%)
>> 
>> vs
>> 
>> Statistics for 1322 bytecoded nmethods for C2:
>>  total in heap  = 8307120 (100%)
>>  header         = 327856 (3.946687%)
>> 
>> 
>> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some fields were changed from `int` to `int16_t` with added corresponding asserts to make sure their values are fit into 16 bits.
>> 
>> I did additional cleanup after recent `CompiledMethod` removal.
>> 
>> Tested tier1-7,stress,xcomp and performance testing.
>
> Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge master
>  - remove trailing space
>  - Shuffle fields initialization
>  - Address comments. Used checked_cast.
>  - Use 16-bits types for header_size and frame_complete_offset arguments
>  - Union fields which usages do not overlap
>  - Moved some fields initialization into init_defaults()
>  - 8329433: Reduce nmethod header size

I remove `ASSERT` blocks to address the last @dean-long comment.

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

PR Comment: https://git.openjdk.org/jdk/pull/18768#issuecomment-2062784402

From dlong at openjdk.org  Thu Apr 18 01:16:59 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 18 Apr 2024 01:16:59 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v8]
In-Reply-To: <dgiye_PwnS18gvpQqDERagHD293R_D0iwcTDNjrtgL8=.c803bb0d-abc5-4a58-a8a5-3ef396c349b4@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
 <dgiye_PwnS18gvpQqDERagHD293R_D0iwcTDNjrtgL8=.c803bb0d-abc5-4a58-a8a5-3ef396c349b4@github.com>
Message-ID: <1HEEQR0o6XO22qTFgrqriq89NEmYyxw3khht6PWlu8U=.245c3378-cdcd-4085-a307-aab5186e6d6d@github.com>

On Thu, 18 Apr 2024 00:41:03 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> This is part of changes which try to reduce size of `nmethod` and `codeblob` data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From 304 to 248 in optimized VM:
>> 
>> Statistics for 1282 bytecoded nmethods for C2:
>>  total in heap = 5560352 (100%)
>>  header = 389728 (7.009053%)
>> 
>> vs
>> 
>> Statistics for 1322 bytecoded nmethods for C2:
>>  total in heap  = 8307120 (100%)
>>  header         = 327856 (3.946687%)
>> 
>> 
>> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some fields were changed from `int` to `int16_t` with added corresponding asserts to make sure their values are fit into 16 bits.
>> 
>> I did additional cleanup after recent `CompiledMethod` removal.
>> 
>> Tested tier1-7,stress,xcomp and performance testing.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comment

Marked as reviewed by dlong (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18768#pullrequestreview-2007632424

From gdub at openjdk.org  Thu Apr 18 07:53:58 2024
From: gdub at openjdk.org (Gilles Duboscq)
Date: Thu, 18 Apr 2024 07:53:58 GMT
Subject: RFR: 8330388: Remove invokedynamic cache index encoding
In-Reply-To: <QbD7B30aa0z4LsbSTZbxGQVFUu5yxpCFiiNZTdskonY=.eaca60d3-73fc-4302-8aa0-c06e5b855cfd@github.com>
References: <QbD7B30aa0z4LsbSTZbxGQVFUu5yxpCFiiNZTdskonY=.eaca60d3-73fc-4302-8aa0-c06e5b855cfd@github.com>
Message-ID: <1XlY7bXwXvhA6OwpvJtYLwKcnEmoNRB7aG1JO1ArEMs=.b32f15a7-296f-4145-9533-fa3ebd6c9aa2@github.com>

On Wed, 17 Apr 2024 15:26:52 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> Before [JDK-8307190](https://bugs.openjdk.org/browse/JDK-8307190), [JDK-8309673](https://bugs.openjdk.org/browse/JDK-8309673), and [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995), invokedynamic operands needed to be rewritten to encoded values to better distinguish indy entries from other cp cache entries. The above changes now distinguish between entries with `to_cp_index()` using the bytecode, which is now propagated by the callers.
> 
> The encoding flips the bits of the index so the encoded index is always negative, leading to access errors if there is no matching decode call. These calls are removed with some methods adjusted to distinguish between indices with the bytecode. Verified with tier 1-5 tests.

src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotConstantPool.java line 720:

> 718:     @Override
> 719:     public JavaMethod lookupMethod(int rawIndex, int opcode, ResolvedJavaMethod caller) {
> 720:         int which = rawIndex;

We could get rid of that intermediate variable now and just use `rawIndex` below.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18819#discussion_r1570192972

From dnsimon at openjdk.org  Thu Apr 18 08:26:58 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 18 Apr 2024 08:26:58 GMT
Subject: RFR: 8330388: Remove invokedynamic cache index encoding
In-Reply-To: <JQESdDCAbijnaCyub9f3AK1rXr9JzamIexYhPywvVDM=.f84c1110-938d-4fdb-9abb-17326bd610ad@github.com>
References: <QbD7B30aa0z4LsbSTZbxGQVFUu5yxpCFiiNZTdskonY=.eaca60d3-73fc-4302-8aa0-c06e5b855cfd@github.com>
 <JQESdDCAbijnaCyub9f3AK1rXr9JzamIexYhPywvVDM=.f84c1110-938d-4fdb-9abb-17326bd610ad@github.com>
Message-ID: <nKF11wrrwfN2juo9Azkw98X96qS6echfpLXqprTX0aE=.dfa6b434-25b4-4e43-a409-9e8fb28f2af2@github.com>

On Wed, 17 Apr 2024 22:58:21 GMT, Dean Long <dlong at openjdk.org> wrote:

> @dougxc should check JVMCI changes.

Thanks for the heads up. I've asked @matias9927 to double check these changes against libgraal which should address any concerns about how this change impacts Graal.

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

PR Comment: https://git.openjdk.org/jdk/pull/18819#issuecomment-2063308834

From sgehwolf at openjdk.org  Thu Apr 18 09:54:56 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 18 Apr 2024 09:54:56 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v2]
In-Reply-To: <AyhwTYv3k8rFJ2k4nQT93fwyO_1gXMALMmmckLwrfpw=.2994f76e-ca36-4013-b03b-d4006349ad38@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <trUwK5rQzvQtPnGLg7PeAvOdtPfJHFpEKdtyJcLj6Bw=.2435ad46-f513-4f20-952d-70c1b1f24924@github.com>
 <E0c7XjQsTAjQ3oBR-9IrqKS-o6eaMrhYx2WxiRPEFJM=.af4c068c-e43e-460d-9b45-256df9205b28@github.com>
 <XpaCLyqit2xsq95Sou7z9clG7WWTwzIBR16ib0_xlDc=.376b07f0-3efd-4c85-a9c5-a61a4bdc0d61@github.com>
 <AyhwTYv3k8rFJ2k4nQT93fwyO_1gXMALMmmckLwrfpw=.2994f76e-ca36-4013-b03b-d4006349ad38@github.com>
Message-ID: <ZRlHTb5Q36yCkO4GGADw-2sThIQzkW1zDiWAYyJ4Zkk=.14207e13-760e-4bb0-9a75-e4da303c22a8@github.com>

On Wed, 17 Apr 2024 01:07:04 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

>>> IMHO `is_containerized()` is OK to return `false` even when running in a container but with no limitations set.
>> 
>> The idea here is to use this property to tune OpenJDK for in-container, specifically k8s, use. In such a setup it's custom to run a single process within set resource constraints. In order to do this, we need a reliable way to distinguish that vs. non-containerized setup. If somebody really wants to run OpenJDK in a container expecting it to run like a physical OpenJDK deployment, that's when `-XX:-UseContainerSupport` should be used.
>
>> The idea here is to use this property to tune OpenJDK for in-container, specifically k8s, use. In such a setup it's custom to run a single process within set resource constraints.
> 
> The in-container tuning means to use all the available resources. Containers in the real world have some memory limits set which is where my modified patch still correctly identifies it as a container to use all the available resources of the node which is the whole goal of the container detection code.
> 
>> In order to do this, we need a reliable way to distinguish that vs. non-containerized setup.
> 
> I expect it should have been written "We need a reliable way to distinguish real world in-container vs. non-containerized setup. We do not mind behavior for artificial containers on OpenJDK development machines.". Which is what my patch does in an easier and less error-prone way.
> 
>> If somebody really wants to run OpenJDK in a container expecting it to run like a physical OpenJDK deployment, that's when `-XX:-UseContainerSupport` should be used.
> 
> That behaves still the same with my patch.
> 
> Could you give a countercase where my patch behaves wrongly?

@jankratochvil I believe this boils down to what we actually want. Should `OSContainer::is_containerized()` return `false` when run *inside* a container? If so, when is it OK to do that? Should `OSContainer::is_containerized()` return `true` on a physical Linux deployment? IMO, the read-only property of the mount points was something that fit naturally since, we already scan those anyway for (cgv1 vs cgv2 detection). Therefore it was something to consider to make heuristics more accurate.

The truth table of the patch in this PR looks like this:
| `OSContainer::is_containerized()` value  | Actual deployment scenario |
| ------------- | ------------- |
| `true`  | OpenJDK runs in an unprivileged container **without** a cpu/memory limit |
| `true`  | OpenJDK runs in an unprivileged container **with** a cpu/memory limit |
| `true`  | OpenJDK runs in a privileged container **with** a cpu/memory limit |
| `false`  | OpenJDK runs in a privileged container **without** a cpu/memory limit |
| `false`  | OpenJDK runs in a systemd slice **without** a cpu/memory limit |
| `true`  | OpenJDK runs in a systemd slice **with** a cpu/memory limit |
| `false`  | OpenJDK runs on a physical Linux system (VM or bare metal) |

As you can see, the case of "OpenJDK runs in a privileged container *without* a cpu/memory limit" gives the wrong result. However, I consider this a fairly uncommon setup and there isn't really anything we can do to detect this kind of setup. Even if we did manage to detect it, why would we care? It's a question of probability.

> Could you give a countercase where my patch behaves wrongly?

Again, it's not a case of right or wrong IMO. Since we are in the land of heuristics, they will be wrong in some cases. We should make them so that we cover the common cases and, perhaps, are able to use those in serviceability tools to help guide diagnosis and/or further tuning. So far the existing capabilities were OK, but prevent further out-of-the-box tuning and/or accurate data collection.

Your proposed patch (it's one I had in a previous iteration too, fwiw) would also return `false` for the case of "OpenJDK runs in an unprivileged container **without** a cpu/memory limit", which seems counterintuitive if OpenJDK actually runs in a container! What's more, it seems a fairly common case. Also, there is a chance of the OpenJDK heuristics to fail memory/cpu limit detection because of bugs and new developments. It seems the safer option to know that OpenJDK is containerized (using other heuristics) in that case. Maybe that's just me.

Let's have that discussion more broadly and see if we can reach consensus!

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

PR Comment: https://git.openjdk.org/jdk/pull/18201#issuecomment-2063477204

From coleenp at openjdk.org  Thu Apr 18 11:22:00 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 18 Apr 2024 11:22:00 GMT
Subject: RFR: 8330388: Remove invokedynamic cache index encoding
In-Reply-To: <QbD7B30aa0z4LsbSTZbxGQVFUu5yxpCFiiNZTdskonY=.eaca60d3-73fc-4302-8aa0-c06e5b855cfd@github.com>
References: <QbD7B30aa0z4LsbSTZbxGQVFUu5yxpCFiiNZTdskonY=.eaca60d3-73fc-4302-8aa0-c06e5b855cfd@github.com>
Message-ID: <VpqZQjS9MOhC90yh07hDjJgKlwD3-un4k6_rXhjxloU=.4d25685e-6426-49fd-96d0-0ae5aee45cdf@github.com>

On Wed, 17 Apr 2024 15:26:52 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> Before [JDK-8307190](https://bugs.openjdk.org/browse/JDK-8307190), [JDK-8309673](https://bugs.openjdk.org/browse/JDK-8309673), and [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995), invokedynamic operands needed to be rewritten to encoded values to better distinguish indy entries from other cp cache entries. The above changes now distinguish between entries with `to_cp_index()` using the bytecode, which is now propagated by the callers.
> 
> The encoding flips the bits of the index so the encoded index is always negative, leading to access errors if there is no matching decode call. These calls are removed with some methods adjusted to distinguish between indices with the bytecode. Verified with tier 1-5 tests.

To borrow @shipilev's comment from a different PR, Good Riddance!

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18819#pullrequestreview-2008602360

From jkratochvil at openjdk.org  Thu Apr 18 13:30:08 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Thu, 18 Apr 2024 13:30:08 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v2]
In-Reply-To: <trUwK5rQzvQtPnGLg7PeAvOdtPfJHFpEKdtyJcLj6Bw=.2435ad46-f513-4f20-952d-70c1b1f24924@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <trUwK5rQzvQtPnGLg7PeAvOdtPfJHFpEKdtyJcLj6Bw=.2435ad46-f513-4f20-952d-70c1b1f24924@github.com>
Message-ID: <0gUVzigzVfEv1IWV9irog8S3hPme-Aux9fDUWjPO2wc=.fa1648a1-4714-4f74-acc0-22c4250490af@github.com>

On Thu, 11 Apr 2024 12:08:02 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this enhancement to the container detection code which allows it to figure out whether the JVM is actually running inside a container (`podman`, `docker`, `crio`), or with some other means that enforces memory/cpu limits by means of the cgroup filesystem. If neither of those conditions hold, the JVM runs in not containerized mode, addressing the issue described in the JBS tracker. For example, on my Linux system `is_containerized() == false" is being indicated with the following trace log line:
>> 
>> 
>> [0.001s][debug][os,container] OSContainer::init: is_containerized() = false because no cpu or memory limit is present
>> 
>> 
>> This state is being exposed by the Java `Metrics` API class using the new (still JDK internal) `isContainerized()` method. Example:
>> 
>> 
>> java -XshowSettings:system --version
>> Operating System Metrics:
>>     Provider: cgroupv1
>>     System not containerized.
>> openjdk 23-internal 2024-09-17
>> OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk)
>> OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)
>> 
>> 
>> The basic property this is being built on is the observation that the cgroup controllers typically get mounted read only into containers. Note that the current container tests assert that `OSContainer::is_containerized() == true` in various tests. Therefore, using the heuristic of "is any memory or cpu limit present" isn't sufficient. I had considered that in an earlier iteration, but many container tests failed.
>> 
>> Overall, I think, with this patch we improve the current situation of claiming a containerized system being present when it's actually just a regular Linux system.
>> 
>> Testing:
>> 
>> - [x] GHA (risc-v failure seems infra related)
>> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including gtests)
>> - [x] Some manual testing using cri-o
>> 
>> Thoughts?
>
> 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 ten additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - jcheck fixes
>  - Fix tests
>  - Implement Metrics.isContainerized()
>  - Some clean-up
>  - Drop cgroups testing on plain Linux
>  - Implement fall-back logic for non-ro controller mounts
>  - Make find_ro static and local to compilation unit
>  - 8261242: [Linux] OSContainer::is_containerized() returns true

Could not we rename `is_containerized()` to `use_container_limit()` ? As that is the current only purpose of `is_containerized()`.

I did not test it but I expect the values will be:

| your patch | my trivial patch | Actual deployment scenario |
|--------|--------|--------|
| `true` | `false` |OpenJDK runs in an unprivileged container **without** a cpu/memory limit |
| `true` | `true` | OpenJDK runs in an unprivileged container **with** a cpu/memory limit |
| `false` | `false` | OpenJDK runs in a privileged container **without** a cpu/memory limit |
| `true` | `true` | OpenJDK runs in a privileged container **with** a cpu/memory limit |
| `false` | `false` | OpenJDK runs in a systemd slice **without** a cpu/memory limit |
| `true` | `true` | OpenJDK runs in a systemd slice **with** a cpu/memory limit |
| `false` | `false` | OpenJDK runs on a physical Linux system (VM or bare metal) |

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

PR Comment: https://git.openjdk.org/jdk/pull/18201#issuecomment-2063868908

From kvn at openjdk.org  Thu Apr 18 15:05:11 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 18 Apr 2024 15:05:11 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v8]
In-Reply-To: <dgiye_PwnS18gvpQqDERagHD293R_D0iwcTDNjrtgL8=.c803bb0d-abc5-4a58-a8a5-3ef396c349b4@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
 <dgiye_PwnS18gvpQqDERagHD293R_D0iwcTDNjrtgL8=.c803bb0d-abc5-4a58-a8a5-3ef396c349b4@github.com>
Message-ID: <hTzP8L-C6alXj1v_LWclG3uyfiNLM2ArZvxlHyfKyyE=.ed2bd553-56ad-479e-8931-e9d7ce1bb758@github.com>

On Thu, 18 Apr 2024 00:41:03 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> This is part of changes which try to reduce size of `nmethod` and `codeblob` data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From 304 to 248 in optimized VM:
>> 
>> Statistics for 1282 bytecoded nmethods for C2:
>>  total in heap = 5560352 (100%)
>>  header = 389728 (7.009053%)
>> 
>> vs
>> 
>> Statistics for 1322 bytecoded nmethods for C2:
>>  total in heap  = 8307120 (100%)
>>  header         = 327856 (3.946687%)
>> 
>> 
>> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some fields were changed from `int` to `int16_t` with added corresponding asserts to make sure their values are fit into 16 bits.
>> 
>> I did additional cleanup after recent `CompiledMethod` removal.
>> 
>> Tested tier1-7,stress,xcomp and performance testing.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comment

Waiting second review.

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

PR Comment: https://git.openjdk.org/jdk/pull/18768#issuecomment-2064136498

From matsaave at openjdk.org  Thu Apr 18 15:27:02 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 18 Apr 2024 15:27:02 GMT
Subject: RFR: 8330388: Remove invokedynamic cache index encoding
In-Reply-To: <ENt3LP5_1w0ffj8dGmobLgcZxXt_LxGCTvTwGbQLJic=.b680a61f-7cb8-4a34-a42a-be8120f5f7b1@github.com>
References: <QbD7B30aa0z4LsbSTZbxGQVFUu5yxpCFiiNZTdskonY=.eaca60d3-73fc-4302-8aa0-c06e5b855cfd@github.com>
 <ENt3LP5_1w0ffj8dGmobLgcZxXt_LxGCTvTwGbQLJic=.b680a61f-7cb8-4a34-a42a-be8120f5f7b1@github.com>
Message-ID: <Gv2q9uwR5kXn4L_-J0G0lcweGFiIdOej3bJ0cM3OOIg=.e6f2aa5d-2515-4d1a-9600-c524ba5ff153@github.com>

On Wed, 17 Apr 2024 22:43:38 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Before [JDK-8307190](https://bugs.openjdk.org/browse/JDK-8307190), [JDK-8309673](https://bugs.openjdk.org/browse/JDK-8309673), and [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995), invokedynamic operands needed to be rewritten to encoded values to better distinguish indy entries from other cp cache entries. The above changes now distinguish between entries with `to_cp_index()` using the bytecode, which is now propagated by the callers.
>> 
>> The encoding flips the bits of the index so the encoded index is always negative, leading to access errors if there is no matching decode call. These calls are removed with some methods adjusted to distinguish between indices with the bytecode. Verified with tier 1-5 tests.
>
> src/hotspot/share/classfile/resolutionErrors.hpp line 60:
> 
>> 58: 
>> 59:   // This function is used to encode an invokedynamic index to differentiate it from a
>> 60:   // constant pool index.  It assumes it is being called with a index that is less than 0
> 
> Is this comment still correct?

The last sentence is no longer valid, thanks for catching this!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18819#discussion_r1570969645

From matsaave at openjdk.org  Thu Apr 18 15:37:58 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 18 Apr 2024 15:37:58 GMT
Subject: RFR: 8330388: Remove invokedynamic cache index encoding
In-Reply-To: <-5i_BDguO1qWOP0GnYK4pTeMMW4IhlV3LkqLPFs4vAw=.060c849a-de1a-4888-943e-80b9ed4eecf2@github.com>
References: <QbD7B30aa0z4LsbSTZbxGQVFUu5yxpCFiiNZTdskonY=.eaca60d3-73fc-4302-8aa0-c06e5b855cfd@github.com>
 <-5i_BDguO1qWOP0GnYK4pTeMMW4IhlV3LkqLPFs4vAw=.060c849a-de1a-4888-943e-80b9ed4eecf2@github.com>
Message-ID: <jSZRMFg1NX_HlceHWu7THnUEsum61BihIHuGRhDHNOM=.716f537b-dddb-4814-aabc-a2310ecf9d58@github.com>

On Wed, 17 Apr 2024 22:48:16 GMT, Dean Long <dlong at openjdk.org> wrote:

> Did you consider minimizing changes by leaving decode_invokedynamic_index/encode_invokedynamic_index calls in place, but having the implementations not change the value?

The intention from the start was to remove the encode/decode methods because they have been made unnecessary thanks to the changes mentioned in the description. As the author of the previously mentioned changes that overhauled the cpcache, this change should have been included in one of those PRs, but I must have forgotten! Leaving the calls in even if they did nothing would just make the code confusing and might become a red herring if other issues in the area come up.

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

PR Comment: https://git.openjdk.org/jdk/pull/18819#issuecomment-2064263944

From matsaave at openjdk.org  Thu Apr 18 16:22:31 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 18 Apr 2024 16:22:31 GMT
Subject: RFR: 8330388: Remove invokedynamic cache index encoding [v2]
In-Reply-To: <ENt3LP5_1w0ffj8dGmobLgcZxXt_LxGCTvTwGbQLJic=.b680a61f-7cb8-4a34-a42a-be8120f5f7b1@github.com>
References: <QbD7B30aa0z4LsbSTZbxGQVFUu5yxpCFiiNZTdskonY=.eaca60d3-73fc-4302-8aa0-c06e5b855cfd@github.com>
 <ENt3LP5_1w0ffj8dGmobLgcZxXt_LxGCTvTwGbQLJic=.b680a61f-7cb8-4a34-a42a-be8120f5f7b1@github.com>
Message-ID: <tsPPTzL2wMGo8zQjHodyujyydjTCMaHCmZ-tj6S4cx8=.da676061-19ec-4261-9d62-e7e5ca3518ac@github.com>

On Wed, 17 Apr 2024 22:41:08 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Dean and Gilles comments
>
> src/hotspot/share/ci/ciEnv.cpp line 1513:
> 
>> 1511:     // process the BSM
>> 1512:     int pool_index = indy_info->constant_pool_index();
>> 1513:     BootstrapInfo bootstrap_specifier(cp, pool_index, indy_index);
> 
> Why not just change the incoming parameter name to `index`?

`indy_index` is used frequently even in functions that are only used in the context of invokedynamic. I think it helps with clarity.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18819#discussion_r1571043673

From matsaave at openjdk.org  Thu Apr 18 16:22:31 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 18 Apr 2024 16:22:31 GMT
Subject: RFR: 8330388: Remove invokedynamic cache index encoding [v2]
In-Reply-To: <QbD7B30aa0z4LsbSTZbxGQVFUu5yxpCFiiNZTdskonY=.eaca60d3-73fc-4302-8aa0-c06e5b855cfd@github.com>
References: <QbD7B30aa0z4LsbSTZbxGQVFUu5yxpCFiiNZTdskonY=.eaca60d3-73fc-4302-8aa0-c06e5b855cfd@github.com>
Message-ID: <Jn3By48SnhRcPCQZunBMhOSpnrwx3VwkX9YvP9MPZ1g=.738766a7-4c68-4f7b-b252-1a4204c744f2@github.com>

> Before [JDK-8307190](https://bugs.openjdk.org/browse/JDK-8307190), [JDK-8309673](https://bugs.openjdk.org/browse/JDK-8309673), and [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995), invokedynamic operands needed to be rewritten to encoded values to better distinguish indy entries from other cp cache entries. The above changes now distinguish between entries with `to_cp_index()` using the bytecode, which is now propagated by the callers.
> 
> The encoding flips the bits of the index so the encoded index is always negative, leading to access errors if there is no matching decode call. These calls are removed with some methods adjusted to distinguish between indices with the bytecode. Verified with tier 1-5 tests.

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Dean and Gilles comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18819/files
  - new: https://git.openjdk.org/jdk/pull/18819/files/87926aee..3ef92512

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

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

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

From sgehwolf at openjdk.org  Thu Apr 18 16:38:56 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 18 Apr 2024 16:38:56 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v2]
In-Reply-To: <0gUVzigzVfEv1IWV9irog8S3hPme-Aux9fDUWjPO2wc=.fa1648a1-4714-4f74-acc0-22c4250490af@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <trUwK5rQzvQtPnGLg7PeAvOdtPfJHFpEKdtyJcLj6Bw=.2435ad46-f513-4f20-952d-70c1b1f24924@github.com>
 <0gUVzigzVfEv1IWV9irog8S3hPme-Aux9fDUWjPO2wc=.fa1648a1-4714-4f74-acc0-22c4250490af@github.com>
Message-ID: <HtJgC1SfZtVLKBjtlK9s6BcZQu4pQYjhSAmqEuO1EnQ=.098a6603-10bb-4924-8d1c-5248f73d18d2@github.com>

On Thu, 18 Apr 2024 13:27:38 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> Could not we rename `is_containerized()` to `use_container_limit()` ? As that is the current only purpose of `is_containerized()`.

I'm not sure. There is value to have `is_containerized()` like it would behave after this patch. Specifically the first table row difference in [your comment](https://github.com/openjdk/jdk/pull/18201#issuecomment-2063868908) concerns me. JVMs running in a container without limit wouldn't be detected as "containerized". That seems a large share of deployments to miss.

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

PR Comment: https://git.openjdk.org/jdk/pull/18201#issuecomment-2064487567

From larry.cable at oracle.com  Thu Apr 18 17:57:04 2024
From: larry.cable at oracle.com (Laurence Cable)
Date: Thu, 18 Apr 2024 10:57:04 -0700
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns
 true when run outside a container [v2]
In-Reply-To: <HtJgC1SfZtVLKBjtlK9s6BcZQu4pQYjhSAmqEuO1EnQ=.098a6603-10bb-4924-8d1c-5248f73d18d2@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <trUwK5rQzvQtPnGLg7PeAvOdtPfJHFpEKdtyJcLj6Bw=.2435ad46-f513-4f20-952d-70c1b1f24924@github.com>
 <0gUVzigzVfEv1IWV9irog8S3hPme-Aux9fDUWjPO2wc=.fa1648a1-4714-4f74-acc0-22c4250490af@github.com>
 <HtJgC1SfZtVLKBjtlK9s6BcZQu4pQYjhSAmqEuO1EnQ=.098a6603-10bb-4924-8d1c-5248f73d18d2@github.com>
Message-ID: <9deff665-8c19-4e36-ac8e-48384629cf63@oracle.com>



On 4/18/24 9:38 AM, Severin Gehwolf wrote:
> On Thu, 18 Apr 2024 13:27:38 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:
>
>> Could not we rename `is_containerized()` to `use_container_limit()` ? As that is the current only purpose of `is_containerized()`.
> I'm not sure. There is value to have `is_containerized()` like it would behave after this patch. Specifically the first table row difference in [your comment](https://github.com/openjdk/jdk/pull/18201#issuecomment-2063868908) concerns me. JVMs running in a container without limit wouldn't be detected as "containerized". That seems a large share of deployments to miss.

agree 100%

>
> -------------
>
> PR Comment: https://git.openjdk.org/jdk/pull/18201#issuecomment-2064487567


From larry.cable at oracle.com  Thu Apr 18 18:02:52 2024
From: larry.cable at oracle.com (Laurence Cable)
Date: Thu, 18 Apr 2024 11:02:52 -0700
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns
 true when run outside a container [v2]
In-Reply-To: <ZRlHTb5Q36yCkO4GGADw-2sThIQzkW1zDiWAYyJ4Zkk=.14207e13-760e-4bb0-9a75-e4da303c22a8@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <trUwK5rQzvQtPnGLg7PeAvOdtPfJHFpEKdtyJcLj6Bw=.2435ad46-f513-4f20-952d-70c1b1f24924@github.com>
 <E0c7XjQsTAjQ3oBR-9IrqKS-o6eaMrhYx2WxiRPEFJM=.af4c068c-e43e-460d-9b45-256df9205b28@github.com>
 <XpaCLyqit2xsq95Sou7z9clG7WWTwzIBR16ib0_xlDc=.376b07f0-3efd-4c85-a9c5-a61a4bdc0d61@github.com>
 <AyhwTYv3k8rFJ2k4nQT93fwyO_1gXMALMmmckLwrfpw=.2994f76e-ca36-4013-b03b-d4006349ad38@github.com>
 <ZRlHTb5Q36yCkO4GGADw-2sThIQzkW1zDiWAYyJ4Zkk=.14207e13-760e-4bb0-9a75-e4da303c22a8@github.com>
Message-ID: <c294bf3f-6df7-4d47-b68d-13b2c2222b5a@oracle.com>



On 4/18/24 2:54 AM, Severin Gehwolf wrote:
> On Wed, 17 Apr 2024 01:07:04 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:
>
>>>> IMHO `is_containerized()` is OK to return `false` even when running in a container but with no limitations set.
>>> The idea here is to use this property to tune OpenJDK for in-container, specifically k8s, use. In such a setup it's custom to run a single process within set resource constraints. In order to do this, we need a reliable way to distinguish that vs. non-containerized setup. If somebody really wants to run OpenJDK in a container expecting it to run like a physical OpenJDK deployment, that's when `-XX:-UseContainerSupport` should be used.
>>> The idea here is to use this property to tune OpenJDK for in-container, specifically k8s, use. In such a setup it's custom to run a single process within set resource constraints.
>> The in-container tuning means to use all the available resources. Containers in the real world have some memory limits set which is where my modified patch still correctly identifies it as a container to use all the available resources of the node which is the whole goal of the container detection code.
>>
>>> In order to do this, we need a reliable way to distinguish that vs. non-containerized setup.
>> I expect it should have been written "We need a reliable way to distinguish real world in-container vs. non-containerized setup. We do not mind behavior for artificial containers on OpenJDK development machines.". Which is what my patch does in an easier and less error-prone way.
>>
>>> If somebody really wants to run OpenJDK in a container expecting it to run like a physical OpenJDK deployment, that's when `-XX:-UseContainerSupport` should be used.
>> That behaves still the same with my patch.
>>
>> Could you give a countercase where my patch behaves wrongly?
> @jankratochvil I believe this boils down to what we actually want. Should `OSContainer::is_containerized()` return `false` when run *inside* a container? If so, when is it OK to do that? Should `OSContainer::is_containerized()` return `true` on a physical Linux deployment? IMO, the read-only property of the mount points was something that fit naturally since, we already scan those anyway for (cgv1 vs cgv2 detection). Therefore it was something to consider to make heuristics more accurate.
>
> The truth table of the patch in this PR looks like this:
> | `OSContainer::is_containerized()` value  | Actual deployment scenario |
> | ------------- | ------------- |
> | `true`  | OpenJDK runs in an unprivileged container **without** a cpu/memory limit |
> | `true`  | OpenJDK runs in an unprivileged container **with** a cpu/memory limit |
> | `true`  | OpenJDK runs in a privileged container **with** a cpu/memory limit |
> | `false`  | OpenJDK runs in a privileged container **without** a cpu/memory limit |
> | `false`  | OpenJDK runs in a systemd slice **without** a cpu/memory limit |
> | `true`  | OpenJDK runs in a systemd slice **with** a cpu/memory limit |
> | `false`  | OpenJDK runs on a physical Linux system (VM or bare metal) |
>
> As you can see, the case of "OpenJDK runs in a privileged container *without* a cpu/memory limit" gives the wrong result. However, I consider this a fairly uncommon setup and there isn't really anything we can do to detect this kind of setup. Even if we did manage to detect it, why would we care? It's a question of probability.
>
>> Could you give a countercase where my patch behaves wrongly?
> Again, it's not a case of right or wrong IMO. Since we are in the land of heuristics, they will be wrong in some cases. We should make them so that we cover the common cases and, perhaps, are able to use those in serviceability tools to help guide diagnosis and/or further tuning. So far the existing capabilities were OK, but prevent further out-of-the-box tuning and/or accurate data collection.

I think (I am agreeing with you Severin) that the goal of the heuristic 
is to inform the JVM (and any associated serviceability tools) that the 
JVM is in a resource constrained/managed execution context...

Rgds

- Larry

>
> Your proposed patch (it's one I had in a previous iteration too, fwiw) would also return `false` for the case of "OpenJDK runs in an unprivileged container **without** a cpu/memory limit", which seems counterintuitive if OpenJDK actually runs in a container! What's more, it seems a fairly common case. Also, there is a chance of the OpenJDK heuristics to fail memory/cpu limit detection because of bugs and new developments. It seems the safer option to know that OpenJDK is containerized (using other heuristics) in that case. Maybe that's just me.
>
> Let's have that discussion more broadly and see if we can reach consensus!
>
> -------------
>
> PR Comment: https://git.openjdk.org/jdk/pull/18201#issuecomment-2063477204


From jjg at openjdk.org  Thu Apr 18 20:52:29 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 18 Apr 2024 20:52:29 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v4]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <p1Ldsyr_hNrd7LEhoThBxZzXEtMZk3siO_ZLFZp43vY=.c61e1870-2db1-4ee8-b157-f6f2b0be1715@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

Jonathan Gibbons 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 five additional commits since the last revision:

 - improve handling of ignorable doc comments
   suppress warning when building test code
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - call `saveDanglingDocComments` for local variable declarations
 - adjust call for `saveDanglingDocComments` for enum members
 - JDK-8303689: javac -Xlint could/should report on "dangling" doc comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18527/files
  - new: https://git.openjdk.org/jdk/pull/18527/files/3f745431..f3670e7a

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

  Stats: 42074 lines in 1058 files changed: 18282 ins; 15937 del; 7855 mod
  Patch: https://git.openjdk.org/jdk/pull/18527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18527/head:pull/18527

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

From jjg at openjdk.org  Thu Apr 18 21:34:13 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 18 Apr 2024 21:34:13 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v5]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <Pw-vAt9fBf-s7YcdBbtzbYdcM49PkNcmvIfbSmYdjYI=.a94e6477-30de-463b-b509-d4cd38f26cd7@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  update test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18527/files
  - new: https://git.openjdk.org/jdk/pull/18527/files/f3670e7a..8ad8b818

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

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

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

From sspitsyn at openjdk.org  Thu Apr 18 21:56:09 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 18 Apr 2024 21:56:09 GMT
Subject: RFR: 8328741:
 serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java failed with
 unexpected owner [v4]
In-Reply-To: <qXonY64Tq0lRSrpqGH86L7qGC1lpTmNZtQk54HFbHG4=.08c6864e-b84b-48ff-90e3-4d0768b42c45@github.com>
References: <qXonY64Tq0lRSrpqGH86L7qGC1lpTmNZtQk54HFbHG4=.08c6864e-b84b-48ff-90e3-4d0768b42c45@github.com>
Message-ID: <bqvxPNF1XX1QRd3U5M1GZXeE-5ddx0s6ukIay9RTB_M=.7fb03a0d-b931-4ee4-ba61-1cabfd4b3cd8@github.com>

> This is the test issue. The `WaitingPT3` thread posted the `MonitorWait` event but has not released the `lockCheck` monitor yet. It has been fixed to wait for each `WaitingTask` thread to really reach the `WAITING` state. The same approach is used for `EnteringTask` threads. It has been fixed to wait for each `EnteringTask` thread to reach the `BLOCKED_ON_MONITOR` state.
> 
> Testing:
>  - Reran the test `serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java` locally
>  - TBD: submit the mach5 tiers 1-6 as well

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

  review: tweak in wait_for_state func to allow exp_state bit mask

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18778/files
  - new: https://git.openjdk.org/jdk/pull/18778/files/68cdd8c7..0b2500d5

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

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

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

From jjg at openjdk.org  Thu Apr 18 21:56:16 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 18 Apr 2024 21:56:16 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v6]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <_EMQ8vgc0hQdgeWdnqirLLAN8Cj6jcxP0belwJffD8A=.2c536c2b-f0e1-49b4-8fc7-e3a9252e20e2@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge with upstream/master
 - update test
 - improve handling of ignorable doc comments
   suppress warning when building test code
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - call `saveDanglingDocComments` for local variable declarations
 - adjust call for `saveDanglingDocComments` for enum members
 - JDK-8303689: javac -Xlint could/should report on "dangling" doc comments

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

Changes: https://git.openjdk.org/jdk/pull/18527/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18527&range=05
  Stats: 488 lines in 61 files changed: 389 ins; 3 del; 96 mod
  Patch: https://git.openjdk.org/jdk/pull/18527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18527/head:pull/18527

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

From amenkov at openjdk.org  Fri Apr 19 00:14:04 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 19 Apr 2024 00:14:04 GMT
Subject: RFR: 8320215: HeapDumper can use DumpWriter buffer during merge
Message-ID: <tImZFe13oYNkG6sz8Wk2RpUawTiym48oxvAS3pXFHWo=.490751ea-331f-4399-b9ee-98a7c179ee30@github.com>

The fix updates HeapMerger to use writer buffer (no need to copy memory, also writer buffer is 1MB instead of 4KB).
Additionally fixed small issue in FileWriter (looks like `ssize_t` instead of `size_t` is a typo, the argument should be unsigned)

Testing: all HeapDump-related tests on Oracle supported platforms

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

Commit messages:
 - fix

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

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

From amenkov at openjdk.org  Fri Apr 19 01:22:15 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 19 Apr 2024 01:22:15 GMT
Subject: RFR: 8329113: Deprecate -XX:+UseNotificationThread
Message-ID: <QhEOdTwHfQbI3r9HemyTHZccwxKaoeGonhXlEnlm33Y=.6ab02510-6fc7-47d5-a3f9-03cb93205b59@github.com>

The fix deprecates -XX:+UseNotificationThread VM option

Testing: tier1-3

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

Commit messages:
 - fix

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

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

From rrich at openjdk.org  Fri Apr 19 07:46:58 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 19 Apr 2024 07:46:58 GMT
Subject: RFR: 8330171: Lazy W^X switch implementation
In-Reply-To: <9eymaXovxUNFdkAkzojFQP5trwl_yyY0jE2GzcMEjR4=.02ee2ef9-c476-4c7c-9e4a-e021425c38bc@github.com>
References: <9eymaXovxUNFdkAkzojFQP5trwl_yyY0jE2GzcMEjR4=.02ee2ef9-c476-4c7c-9e4a-e021425c38bc@github.com>
Message-ID: <DGjOTJjWNyRdiUDzupUmGBzS6N7anW3ECzYAtjRUZOQ=.310e6e2a-a387-407b-a293-a14381c04980@github.com>

On Fri, 12 Apr 2024 14:40:05 GMT, Sergey Nazarkin <snazarki at openjdk.org> wrote:

> An alternative for preemptively switching the W^X thread mode on macOS with an AArch64 CPU. This implementation triggers the switch in response to the SIGBUS signal if the *si_addr* belongs to the CodeCache area. With this approach, it is now feasible to eliminate all WX guards and avoid potentially costly operations. However, no significant improvement or degradation in performance has been observed.  Additionally, considering the issue with AsyncGetCallTrace, the patched JVM has been successfully operated with [asgct_bottom](https://github.com/parttimenerd/asgct_bottom) and [async-profiler](https://github.com/async-profiler/async-profiler). 
> 
> Additional testing:
> - [x] MacOS AArch64 server fastdebug *gtets*
> - [ ] MacOS AArch64 server fastdebug *jtreg:hotspot:tier4*
> - [ ] Benchmarking
> 
> @apangin and @parttimenerd could you please check the patch on your scenarios??

What about granting `WXWrite` only if the current thread is in `_thread_in_vm`?
That would be more restrictive and roughly equivalent how it currently works. Likely there are some places then that should be granted `WXWrite` eagerly because they need `WXWrite` without `_thread_in_vm`. E.g. the JIT compiler threads should have `WXWrite` and never `WXExec` (I assume) which should be checked in the signal handler.

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

PR Comment: https://git.openjdk.org/jdk/pull/18762#issuecomment-2065983074

From sgehwolf at openjdk.org  Fri Apr 19 09:00:00 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 19 Apr 2024 09:00:00 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container [v2]
In-Reply-To: <trUwK5rQzvQtPnGLg7PeAvOdtPfJHFpEKdtyJcLj6Bw=.2435ad46-f513-4f20-952d-70c1b1f24924@github.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <trUwK5rQzvQtPnGLg7PeAvOdtPfJHFpEKdtyJcLj6Bw=.2435ad46-f513-4f20-952d-70c1b1f24924@github.com>
Message-ID: <7GjtMGXbf3rZWHSCnweq2vA_50PWZYL5aRslymkysP0=.fb73e955-0fe3-4a62-a428-ee63d9f819dd@github.com>

On Thu, 11 Apr 2024 12:08:02 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this enhancement to the container detection code which allows it to figure out whether the JVM is actually running inside a container (`podman`, `docker`, `crio`), or with some other means that enforces memory/cpu limits by means of the cgroup filesystem. If neither of those conditions hold, the JVM runs in not containerized mode, addressing the issue described in the JBS tracker. For example, on my Linux system `is_containerized() == false" is being indicated with the following trace log line:
>> 
>> 
>> [0.001s][debug][os,container] OSContainer::init: is_containerized() = false because no cpu or memory limit is present
>> 
>> 
>> This state is being exposed by the Java `Metrics` API class using the new (still JDK internal) `isContainerized()` method. Example:
>> 
>> 
>> java -XshowSettings:system --version
>> Operating System Metrics:
>>     Provider: cgroupv1
>>     System not containerized.
>> openjdk 23-internal 2024-09-17
>> OpenJDK Runtime Environment (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk)
>> OpenJDK 64-Bit Server VM (fastdebug build 23-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)
>> 
>> 
>> The basic property this is being built on is the observation that the cgroup controllers typically get mounted read only into containers. Note that the current container tests assert that `OSContainer::is_containerized() == true` in various tests. Therefore, using the heuristic of "is any memory or cpu limit present" isn't sufficient. I had considered that in an earlier iteration, but many container tests failed.
>> 
>> Overall, I think, with this patch we improve the current situation of claiming a containerized system being present when it's actually just a regular Linux system.
>> 
>> Testing:
>> 
>> - [x] GHA (risc-v failure seems infra related)
>> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including gtests)
>> - [x] Some manual testing using cri-o
>> 
>> Thoughts?
>
> 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 ten additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-8261242-is-containerized-fix
>  - jcheck fixes
>  - Fix tests
>  - Implement Metrics.isContainerized()
>  - Some clean-up
>  - Drop cgroups testing on plain Linux
>  - Implement fall-back logic for non-ro controller mounts
>  - Make find_ro static and local to compilation unit
>  - 8261242: [Linux] OSContainer::is_containerized() returns true

Thanks for your input Larry!

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

PR Comment: https://git.openjdk.org/jdk/pull/18201#issuecomment-2066136268

From iveresov at openjdk.org  Fri Apr 19 16:06:02 2024
From: iveresov at openjdk.org (Igor Veresov)
Date: Fri, 19 Apr 2024 16:06:02 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v8]
In-Reply-To: <dgiye_PwnS18gvpQqDERagHD293R_D0iwcTDNjrtgL8=.c803bb0d-abc5-4a58-a8a5-3ef396c349b4@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
 <dgiye_PwnS18gvpQqDERagHD293R_D0iwcTDNjrtgL8=.c803bb0d-abc5-4a58-a8a5-3ef396c349b4@github.com>
Message-ID: <Vqn4vJ_3cWY359d1XPdc_2opjILtADdm3TQSWJZ1Vmc=.81fc496b-df3b-4574-a64d-d52f6683ddc9@github.com>

On Thu, 18 Apr 2024 00:41:03 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> This is part of changes which try to reduce size of `nmethod` and `codeblob` data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From 304 to 248 in optimized VM:
>> 
>> Statistics for 1282 bytecoded nmethods for C2:
>>  total in heap = 5560352 (100%)
>>  header = 389728 (7.009053%)
>> 
>> vs
>> 
>> Statistics for 1322 bytecoded nmethods for C2:
>>  total in heap  = 8307120 (100%)
>>  header         = 327856 (3.946687%)
>> 
>> 
>> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some fields were changed from `int` to `int16_t` with added corresponding asserts to make sure their values are fit into 16 bits.
>> 
>> I did additional cleanup after recent `CompiledMethod` removal.
>> 
>> Tested tier1-7,stress,xcomp and performance testing.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comment

Looks good.

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

Marked as reviewed by iveresov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18768#pullrequestreview-2011831284

From kvn at openjdk.org  Fri Apr 19 16:12:07 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 19 Apr 2024 16:12:07 GMT
Subject: RFR: 8329433: Reduce nmethod header size [v8]
In-Reply-To: <1HEEQR0o6XO22qTFgrqriq89NEmYyxw3khht6PWlu8U=.245c3378-cdcd-4085-a307-aab5186e6d6d@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
 <dgiye_PwnS18gvpQqDERagHD293R_D0iwcTDNjrtgL8=.c803bb0d-abc5-4a58-a8a5-3ef396c349b4@github.com>
 <1HEEQR0o6XO22qTFgrqriq89NEmYyxw3khht6PWlu8U=.245c3378-cdcd-4085-a307-aab5186e6d6d@github.com>
Message-ID: <ATJsHi6tYawuUmJvLuYpL3dDS9IJmLm6LaZwuy1IeDU=.8758b101-2179-44a2-a453-1a46d21d038a@github.com>

On Thu, 18 Apr 2024 01:14:34 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address comment
>
> Marked as reviewed by dlong (Reviewer).

Thank you @dean-long, @coleenp, @JohnTortugo  and @veresov for reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/18768#issuecomment-2066880731

From kvn at openjdk.org  Fri Apr 19 16:15:04 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 19 Apr 2024 16:15:04 GMT
Subject: Integrated: 8329433: Reduce nmethod header size
In-Reply-To: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
References: <PbifVPyS-IQA5pGRMV822ZVhAV6ZwiZ95g-BhuFgL2s=.fc946663-20af-4bf5-8783-ec911c376109@github.com>
Message-ID: <zdxl93p9gToF8dJjIRvT1XN5FkmAaZcv2GFoh4bLgWc=.fbb2534e-f5cb-49ca-b804-e97d9ba6c6b3@github.com>

On Fri, 12 Apr 2024 22:43:15 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> This is part of changes which try to reduce size of `nmethod` and `codeblob` data vs code in CodeCache.
> These changes reduced size of `nmethod` header from 288 to 232 bytes. From 304 to 248 in optimized VM:
> 
> Statistics for 1282 bytecoded nmethods for C2:
>  total in heap = 5560352 (100%)
>  header = 389728 (7.009053%)
> 
> vs
> 
> Statistics for 1322 bytecoded nmethods for C2:
>  total in heap  = 8307120 (100%)
>  header         = 327856 (3.946687%)
> 
> 
> Several unneeded fields in `nmethod` and `CodeBlob` were removed. Some fields were changed from `int` to `int16_t` with added corresponding asserts to make sure their values are fit into 16 bits.
> 
> I did additional cleanup after recent `CompiledMethod` removal.
> 
> Tested tier1-7,stress,xcomp and performance testing.

This pull request has now been integrated.

Changeset: b704e912
Author:    Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b704e91241b0f84d866f50a8f2c6af240087cb29
Stats:     523 lines in 15 files changed: 135 ins; 186 del; 202 mod

8329433: Reduce nmethod header size

Reviewed-by: dlong, iveresov

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

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

From dcubed at openjdk.org  Fri Apr 19 16:21:58 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 19 Apr 2024 16:21:58 GMT
Subject: RFR: 8329113: Deprecate -XX:+UseNotificationThread
In-Reply-To: <QhEOdTwHfQbI3r9HemyTHZccwxKaoeGonhXlEnlm33Y=.6ab02510-6fc7-47d5-a3f9-03cb93205b59@github.com>
References: <QhEOdTwHfQbI3r9HemyTHZccwxKaoeGonhXlEnlm33Y=.6ab02510-6fc7-47d5-a3f9-03cb93205b59@github.com>
Message-ID: <pClTKZ6y2QOM1kx2R59R-ueKKYT2pJv_FlS1Zyp-qsk=.e41ecf38-f656-43be-82fd-6bf87dfd088a@github.com>

On Fri, 19 Apr 2024 01:16:46 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix deprecates -XX:+UseNotificationThread VM option
> 
> Testing: tier1-3

Thumbs up.

Have you looked for any tests that are using this option?

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

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18852#pullrequestreview-2011868665

From amenkov at openjdk.org  Fri Apr 19 18:09:56 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 19 Apr 2024 18:09:56 GMT
Subject: RFR: 8329113: Deprecate -XX:+UseNotificationThread
In-Reply-To: <pClTKZ6y2QOM1kx2R59R-ueKKYT2pJv_FlS1Zyp-qsk=.e41ecf38-f656-43be-82fd-6bf87dfd088a@github.com>
References: <QhEOdTwHfQbI3r9HemyTHZccwxKaoeGonhXlEnlm33Y=.6ab02510-6fc7-47d5-a3f9-03cb93205b59@github.com>
 <pClTKZ6y2QOM1kx2R59R-ueKKYT2pJv_FlS1Zyp-qsk=.e41ecf38-f656-43be-82fd-6bf87dfd088a@github.com>
Message-ID: <tKZ7tFJCnbAHubp3yBKmZI35IjOO7Y2UEbPzD7u7s5M=.5dc6c55c-33b4-4d4e-b776-568bcbc42c2f@github.com>

On Fri, 19 Apr 2024 16:18:56 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Have you looked for any tests that are using this option?

No tests use the option

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

PR Comment: https://git.openjdk.org/jdk/pull/18852#issuecomment-2067059488

From duke at openjdk.org  Sat Apr 20 02:13:51 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Sat, 20 Apr 2024 02:13:51 GMT
Subject: RFR: 8330694: Rename 'HeapRegion' to 'G1HeapRegion'
Message-ID: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>

follow up 8267941

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

Commit messages:
 - rename

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

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

From cjplummer at openjdk.org  Sat Apr 20 03:15:37 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 20 Apr 2024 03:15:37 GMT
Subject: RFR: 8330694: Rename 'HeapRegion' to 'G1HeapRegion'
In-Reply-To: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
Message-ID: <cEoQBkFrlJvXTqNd0R1YETghp7tXpfL7h7fSF0nFXU0=.8ad29c60-7742-4f97-a045-fb7b2dd7cac8@github.com>

On Sat, 20 Apr 2024 02:04:20 GMT, Lei Zaakjyu <duke at openjdk.org> wrote:

> follow up 8267941

Functionally the SA changes look good, but I pointed out a few other places that you might also want to consider doing renames for.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PointerFinder.java line 123:

> 121:       if (heap instanceof G1CollectedHeap) {
> 122:         G1CollectedHeap g1 = (G1CollectedHeap)heap;
> 123:         loc.hr = g1.heapRegionForAddress(a);

"g1HeapRegionForAddress"?

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PointerFinder.java line 126:

> 124:         // We don't assert that loc.hr is not null like we do for the SerialHeap. This is
> 125:         // because heap.isIn(a) can return true if the address is anywhere in G1's mapped
> 126:         // memory, even if that area of memory is not in use by a G1 G1HeapRegion. So there

Suggestion:

        // memory, even if that area of memory is not in use by a G1HeapRegion. So there

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PointerLocation.java line 131:

> 129:   }
> 130: 
> 131:   public G1HeapRegion getHeapRegion() {

Do we want to rename to getG1HeapRegion?

test/hotspot/jtreg/serviceability/sa/TestG1HeapRegion.java line 62:

> 60:             agent.attach(Integer.parseInt(pid));
> 61:             G1CollectedHeap heap = (G1CollectedHeap)VM.getVM().getUniverse().heap();
> 62:             G1HeapRegion hr = heap.hrm().heapRegionIterator().next();

"g1HeapRegionIterator"?

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

PR Review: https://git.openjdk.org/jdk/pull/18871#pullrequestreview-2013005488
PR Review Comment: https://git.openjdk.org/jdk/pull/18871#discussion_r1573125957
PR Review Comment: https://git.openjdk.org/jdk/pull/18871#discussion_r1573124198
PR Review Comment: https://git.openjdk.org/jdk/pull/18871#discussion_r1573124436
PR Review Comment: https://git.openjdk.org/jdk/pull/18871#discussion_r1573125643

From kbarrett at openjdk.org  Sat Apr 20 04:21:28 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 20 Apr 2024 04:21:28 GMT
Subject: RFR: 8330694: Rename 'HeapRegion' to 'G1HeapRegion'
In-Reply-To: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
Message-ID: <K2pywLpUKJsQzLvkMdkhb2eRfC1M03uwOipaMmuIcYE=.38bd4069-eb61-486e-8b08-35b0be986923@github.com>

On Sat, 20 Apr 2024 02:04:20 GMT, Lei Zaakjyu <duke at openjdk.org> wrote:

> follow up 8267941

So much scrolling :)

Looks good.  Just a few very minor nits for which I don't need to re-review.

src/hotspot/share/cds/archiveHeapWriter.cpp line 90:

> 88: 
> 89:     guarantee(UseG1GC, "implementation limitation");
> 90:     guarantee(MIN_GC_REGION_ALIGNMENT <= /*G1*/G1HeapRegion::min_region_size_in_words() * HeapWordSize, "must be");

The "/*G1*/" comment should be removed.

src/hotspot/share/gc/g1/g1ConcurrentMark.hpp line 761:

> 759: 
> 760:   // Region this task is scanning, null if we're not scanning any
> 761:   G1HeapRegion*                 _curr_region;

Adjust indentation of member name to (re)match those nearby.

src/hotspot/share/gc/g1/g1ConcurrentMarkBitMap.hpp line 39:

> 37: class G1CMTask;
> 38: class G1ConcurrentMark;
> 39: class G1HeapRegion;

With this forward declaration rename being the only change, I wonder if the declaration is even
needed.  Try deleting it, but keep if removing produces non-trivial effects elsewhere.

src/hotspot/share/gc/g1/g1FullGCCompactionPoint.hpp line 40:

> 38:   G1FullCollector* _collector;
> 39:   G1HeapRegion* _current_region;
> 40:   HeapWord*   _compaction_top;

Tidy indentation of `_compaction_top`.  My preference would be to remove extra whitespace before it,
rather than adding to (re)line up with new position of `_current_region`.

src/hotspot/share/gc/g1/g1OopClosures.hpp line 33:

> 31: #include "oops/markWord.hpp"
> 32: 
> 33: class G1HeapRegion;

With no other changes in this file, maybe this forward declaration isn't needed at all?  But keep for
now if removal leads to non-trivial additional changes.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18871#pullrequestreview-2013013903
PR Review Comment: https://git.openjdk.org/jdk/pull/18871#discussion_r1573137157
PR Review Comment: https://git.openjdk.org/jdk/pull/18871#discussion_r1573138750
PR Review Comment: https://git.openjdk.org/jdk/pull/18871#discussion_r1573139162
PR Review Comment: https://git.openjdk.org/jdk/pull/18871#discussion_r1573140388
PR Review Comment: https://git.openjdk.org/jdk/pull/18871#discussion_r1573141541

From duke at openjdk.org  Sat Apr 20 06:21:41 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Sat, 20 Apr 2024 06:21:41 GMT
Subject: RFR: 8330694: Rename 'HeapRegion' to 'G1HeapRegion' [v2]
In-Reply-To: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
Message-ID: <r61jF2UoFkvXKC-KC73amJb4tyA1DUjYRXuAmDI-Cxs=.d5048cbe-9d5a-4968-8de6-ac8e9258fa9f@github.com>

> follow up 8267941

Lei Zaakjyu has updated the pull request incrementally with one additional commit since the last revision:

  tidy up

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18871/files
  - new: https://git.openjdk.org/jdk/pull/18871/files/4fe5badc..cae3efd0

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

  Stats: 5 lines in 5 files changed: 0 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18871.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18871/head:pull/18871

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

From duke at openjdk.org  Sat Apr 20 08:44:45 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Sat, 20 Apr 2024 08:44:45 GMT
Subject: RFR: 8330694: Rename 'HeapRegion' to 'G1HeapRegion' [v3]
In-Reply-To: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
Message-ID: <gsmcE1G9ocReBIYX4PxFwu98WPE6Gg-QHWe7u-QGqVU=.7b9f1be3-38c0-446c-8c06-e9d2e863a7c5@github.com>

> follow up 8267941

Lei Zaakjyu has updated the pull request incrementally with one additional commit since the last revision:

  also tidy up

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18871/files
  - new: https://git.openjdk.org/jdk/pull/18871/files/cae3efd0..f02334fd

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

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

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

From tschatzl at openjdk.org  Mon Apr 22 08:12:34 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 22 Apr 2024 08:12:34 GMT
Subject: RFR: 8330694: Rename 'HeapRegion' to 'G1HeapRegion' [v3]
In-Reply-To: <gsmcE1G9ocReBIYX4PxFwu98WPE6Gg-QHWe7u-QGqVU=.7b9f1be3-38c0-446c-8c06-e9d2e863a7c5@github.com>
References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
 <gsmcE1G9ocReBIYX4PxFwu98WPE6Gg-QHWe7u-QGqVU=.7b9f1be3-38c0-446c-8c06-e9d2e863a7c5@github.com>
Message-ID: <g84_lkm4eQ_U87U0pbDcjVQG3vPJ-1yHRWOHM3gtfUc=.6de47486-3df7-441f-961b-d6ffd594cf3a@github.com>

On Sat, 20 Apr 2024 08:44:45 GMT, Lei Zaakjyu <duke at openjdk.org> wrote:

>> follow up 8267941
>
> Lei Zaakjyu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   also tidy up

Indentation issues. I will run the higher tier SA tests just for verification.

There are still more classes related to `HeapRegion` that need the G1 prefix. Not entirely sure they should be changed with this change (probably not exhaustive) but it would be desirable to change them as well rather sooner than later:


HeapRegionClosure
HeapRegionRange
HeapRegionIndexClosure
HeapRegionRemSet
HeapRegionSetBase
HeapRegionSetChecker
HeapRegionSet
FreeRegionListIterator
FreeRegionList

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 157:

> 155: 
> 156: G1HeapRegion* G1CollectedHeap::new_heap_region(uint hrs_index,
> 157:                                              MemRegion mr) {

Indentation

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 166:

> 164:                                         HeapRegionType type,
> 165:                                         bool do_expand,
> 166:                                         uint node_index) {

Indentation

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 999:

> 997:   size_t aligned_expand_bytes = ReservedSpace::page_align_size_up(expand_bytes);
> 998:   aligned_expand_bytes = align_up(aligned_expand_bytes,
> 999:                                        G1HeapRegion::GrainBytes);

Just use a single line, otherwise indent correctly.

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1044:

> 1042:     ReservedSpace::page_align_size_down(shrink_bytes);
> 1043:   aligned_shrink_bytes = align_down(aligned_shrink_bytes,
> 1044:                                          G1HeapRegion::GrainBytes);

Indentation/use single line.

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2862:

> 2860:                                               HeapRegionType::Eden,
> 2861:                                               false /* do_expand */,
> 2862:                                               node_index);

Indentation

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2916:

> 2914:                                             type,
> 2915:                                             true /* do_expand */,
> 2916:                                             node_index);

Indentation

src/hotspot/share/gc/g1/g1CollectedHeap.hpp line 396:

> 394:                          HeapRegionType type,
> 395:                          bool do_expand,
> 396:                          uint node_index = G1NUMA::AnyNodeIndex);

Indentation

src/hotspot/share/gc/g1/g1CollectionSetChooser.hpp line 43:

> 41: public:
> 42:   static size_t mixed_gc_live_threshold_bytes() {
> 43:     return G1HeapRegion::GrainBytes * (size_t) G1MixedGCLiveThresholdPercent / 100;

Suggestion:

    return G1HeapRegion::GrainBytes * (size_t)G1MixedGCLiveThresholdPercent / 100;

Pre-existing

src/hotspot/share/gc/g1/g1HeapRegionManager.cpp line 537:

> 535:   // committed, expand at that index.
> 536:   for (uint curr = reserved_length(); curr-- > 0;) {
> 537:     G1HeapRegion *hr = _regions.get_by_index(curr);

Suggestion:

    G1HeapRegion* hr = _regions.get_by_index(curr);

Pre-existing

src/hotspot/share/gc/g1/g1HeapRegionManager.cpp line 805:

> 803:     FreeRegionList *free_list = worker_freelist(worker_id);
> 804:     for (uint i = start; i < end; i++) {
> 805:       G1HeapRegion *region = _hrm->at_or_null(i);

Suggestion:

      G1HeapRegion* region = _hrm->at_or_null(i);

src/hotspot/share/gc/g1/g1HeapRegionSet.hpp line 248:

> 246: private:
> 247:   FreeRegionList* _list;
> 248:   G1HeapRegion*     _curr;

Suggestion:

  G1HeapRegion*   _curr;

src/hotspot/share/gc/g1/g1HeapVerifier.cpp line 201:

> 199:   G1CollectedHeap* _g1h;
> 200:   size_t _live_bytes;
> 201:   G1HeapRegion *_hr;

Suggestion:

  G1HeapRegion* _hr;

pre-existing

src/hotspot/share/gc/g1/g1HeapVerifier.cpp line 205:

> 203: 
> 204: public:
> 205:   VerifyObjsInRegionClosure(G1HeapRegion *hr, VerifyOption vo)

Suggestion:

  VerifyObjsInRegionClosure(G1HeapRegion* hr, VerifyOption vo)

src/hotspot/share/gc/g1/vmStructs_g1.hpp line 38:

> 36:                                                                               \
> 37:   static_field(G1HeapRegion, GrainBytes,        size_t)                         \
> 38:   static_field(G1HeapRegion, LogOfHRGrainBytes, uint)                           \

Suggestion:

  static_field(G1HeapRegion, GrainBytes,        size_t)                       \
  static_field(G1HeapRegion, LogOfHRGrainBytes, uint)                         \

src/hotspot/share/gc/g1/vmStructs_g1.hpp line 44:

> 42:   nonstatic_field(G1HeapRegion, _top,            HeapWord* volatile)            \
> 43:   nonstatic_field(G1HeapRegion, _end,            HeapWord* const)               \
> 44:   volatile_nonstatic_field(G1HeapRegion, _pinned_object_count, size_t)          \

Suggestion:

  nonstatic_field(G1HeapRegion, _type,           HeapRegionType)              \
  nonstatic_field(G1HeapRegion, _bottom,         HeapWord* const)             \
  nonstatic_field(G1HeapRegion, _top,            HeapWord* volatile)          \
  nonstatic_field(G1HeapRegion, _end,            HeapWord* const)             \
  volatile_nonstatic_field(G1HeapRegion, _pinned_object_count, size_t)        \

src/hotspot/share/gc/g1/vmStructs_g1.hpp line 96:

> 94:   declare_type(G1CollectedHeap, CollectedHeap)                                \
> 95:                                                                               \
> 96:   declare_toplevel_type(G1HeapRegion)                                           \

Suggestion:

  declare_toplevel_type(G1HeapRegion)                                         \

src/hotspot/share/gc/g1/vmStructs_g1.hpp line 106:

> 104:                                                                               \
> 105:   declare_toplevel_type(G1CollectedHeap*)                                     \
> 106:   declare_toplevel_type(G1HeapRegion*)                                          \

Suggestion:

  declare_toplevel_type(G1HeapRegion*)                                        \

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1HeapRegionTable.java line 93:

> 91:     }
> 92: 
> 93:     private class HeapRegionIterator implements Iterator<G1HeapRegion> {

Should probably be `G1HeapRegionIterator`

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/HeapSummary.java line 90:

> 88:       printValMB("MaxMetaspaceSize         = ", getFlagValue("MaxMetaspaceSize", flagMap));
> 89:       if (heap instanceof G1CollectedHeap) {
> 90:         printValMB("G1HeapRegionSize         = ", G1HeapRegion.grainBytes());

Suggestion:

        printValMB("G1HeapRegionSize       = ", G1HeapRegion.grainBytes());

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

Changes requested by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18871#pullrequestreview-2013971784
PR Review: https://git.openjdk.org/jdk/pull/18871#pullrequestreview-2014068153
PR Review Comment: https://git.openjdk.org/jdk/pull/18871#discussion_r1574262994
PR Review Comment: https://git.openjdk.org/jdk/pull/18871#discussion_r1574263232
PR Review Comment: https://git.openjdk.org/jdk/pull/18871#discussion_r1574264505
PR Review Comment: https://git.openjdk.org/jdk/pull/18871#discussion_r1574264972
PR Review Comment: https://git.openjdk.org/jdk/pull/18871#discussion_r1574266207
PR Review Comment: https://git.openjdk.org/jdk/pull/18871#discussion_r1574266517
PR Review Comment: https://git.openjdk.org/jdk/pull/18871#discussion_r1574267075
PR Review Comment: https://git.openjdk.org/jdk/pull/18871#discussion_r1574271446
PR Review Comment: https://git.openjdk.org/jdk/pull/18871#discussion_r1574277670
PR Review Comment: https://git.openjdk.org/jdk/pull/18871#discussion_r1574278045
PR Review Comment: https://git.openjdk.org/jdk/pull/18871#discussion_r1574280865
PR Review Comment: https://git.openjdk.org/jdk/pull/18871#discussion_r1574281852
PR Review Comment: https://git.openjdk.org/jdk/pull/18871#discussion_r1574282056
PR Review Comment: https://git.openjdk.org/jdk/pull/18871#discussion_r1574293124
PR Review Comment: https://git.openjdk.org/jdk/pull/18871#discussion_r1574293556
PR Review Comment: https://git.openjdk.org/jdk/pull/18871#discussion_r1574293917
PR Review Comment: https://git.openjdk.org/jdk/pull/18871#discussion_r1574294107
PR Review Comment: https://git.openjdk.org/jdk/pull/18871#discussion_r1574295929
PR Review Comment: https://git.openjdk.org/jdk/pull/18871#discussion_r1574297949

From aturbanov at openjdk.org  Mon Apr 22 11:24:29 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 22 Apr 2024 11:24:29 GMT
Subject: RFR: 8330534: Update nsk/jdwp tests to use driver instead of
 othervm
In-Reply-To: <-E7U6V_sADPCLdV_Gj37G-0glwUswNfxNyNw43jz120=.436faccd-f4ef-4209-b550-74a04b413ad2@github.com>
References: <-E7U6V_sADPCLdV_Gj37G-0glwUswNfxNyNw43jz120=.436faccd-f4ef-4209-b550-74a04b413ad2@github.com>
Message-ID: <jKqiQ2JTRc5nhMKuzBPlkCv3yaSfUVEbwpy69cZ_GOU=.cda8ed5a-b094-445c-9133-abcedaa5d594@github.com>

On Wed, 17 Apr 2024 20:19:49 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The jdwp tests use debugger and debugee. There is no goal to execute debugger part with all VM flags, they are needed to be used with debugee VM only.
> The change is all tests is to don't use System.exit() and use 'driver' instead of othervm.
> test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeBinder.java
> is updated to correctly set classpath for debugee

test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/ForceEarlyReturn/forceEarlyReturn001/forceEarlyReturn001.java line 127:

> 125: 
> 126:     public static void main (String argv[]) {
> 127:         int result = run(argv,System.out);

Suggestion:

        int result = run(argv, System.out);

test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/Interrupt/interrupt001.java line 93:

> 91:      */
> 92:     public static void main (String argv[]) {
> 93:         int result = run(argv,System.out);

Suggestion:

        int result = run(argv, System.out);

test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/Name/name001.java line 90:

> 88:      */
> 89:     public static void main (String argv[]) {
> 90:         int result = run(argv,System.out);

Suggestion:

        int result = run(argv, System.out);

test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/OwnedMonitors/ownmonitors001.java line 101:

> 99:      */
> 100:     public static void main (String argv[]) {
> 101:         int result = run(argv,System.out);

Suggestion:

        int result = run(argv, System.out);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18826#discussion_r1574589699
PR Review Comment: https://git.openjdk.org/jdk/pull/18826#discussion_r1574590099
PR Review Comment: https://git.openjdk.org/jdk/pull/18826#discussion_r1574590307
PR Review Comment: https://git.openjdk.org/jdk/pull/18826#discussion_r1574590456

From jkratochvil at openjdk.org  Mon Apr 22 13:59:30 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Mon, 22 Apr 2024 13:59:30 GMT
Subject: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true
 when run outside a container
In-Reply-To: <c294bf3f-6df7-4d47-b68d-13b2c2222b5a@oracle.com>
References: <ElCWVtphfdgi651yIzNsfJS3C5ewhpvOH9ZXjqt3PFE=.de11a3f2-c2fd-4cc4-8c6d-e20f9c8de03d@github.com>
 <c294bf3f-6df7-4d47-b68d-13b2c2222b5a@oracle.com>
Message-ID: <bocf_l6kKagKeqgEhID2Y4UN-yxMC3tL_lXcrFfgyWA=.24552163-bf2e-4e13-8c47-40a65a36f882@github.com>

On Fri, 19 Apr 2024 05:18:51 GMT, Laurence Cable <larry.cable at oracle.com> wrote:

> I think (I am agreeing with you Severin) that the goal of the heuristic is to inform the JVM (and any associated serviceability tools) that the JVM is in a resource constrained/managed execution context...

"resource constrained" (my patch) vs. "managed" (this patch) is the difference of the two patches being discussed.

Anyway in this patch one could unify naming across variables/parameters, the same value is called `_is_ro`, `is_read_only`, `ro_opt`, `read_only`, `ro`.

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

PR Comment: https://git.openjdk.org/jdk/pull/18201#issuecomment-2069537759

From gli at openjdk.org  Mon Apr 22 16:30:39 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Mon, 22 Apr 2024 16:30:39 GMT
Subject: RFR: 8330155: Serial: Remove TenuredSpace
Message-ID: <akIgBAk_kI6GQ8orQgn1h1KDPcs1H2AZlq9EHgVLYWI=.e6363e84-1349-464a-98c9-232ba97c2758@github.com>

Hi all,

This patch removes the class `TenuredSpace` and adjusts its usages. After removing `TenuredSpace`, the file `space.inline.hpp` is empty, so I remove this file and change the included header file to `space.hpp`.

The test `make test-tier1_gc` passed locally. Thanks for taking the time to review.

Best Regards,
-- Guoxiong

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

Commit messages:
 - JDK-8330155

Changes: https://git.openjdk.org/jdk/pull/18894/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18894&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330155
  Stats: 162 lines in 21 files changed: 10 ins; 127 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/18894.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18894/head:pull/18894

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

From ayang at openjdk.org  Mon Apr 22 16:58:28 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 22 Apr 2024 16:58:28 GMT
Subject: RFR: 8330155: Serial: Remove TenuredSpace
In-Reply-To: <akIgBAk_kI6GQ8orQgn1h1KDPcs1H2AZlq9EHgVLYWI=.e6363e84-1349-464a-98c9-232ba97c2758@github.com>
References: <akIgBAk_kI6GQ8orQgn1h1KDPcs1H2AZlq9EHgVLYWI=.e6363e84-1349-464a-98c9-232ba97c2758@github.com>
Message-ID: <S22i2cp2Wrkqe-iRhje20i7D_IfrYY1yi1w-JbuTuqc=.81161eaa-fae3-4a71-b12b-0297cbb154e5@github.com>

On Mon, 22 Apr 2024 16:24:06 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch removes the class `TenuredSpace` and adjusts its usages. After removing `TenuredSpace`, the file `space.inline.hpp` is empty, so I remove this file and change the included header file to `space.hpp`.
> 
> The test `make test-tier1_gc` passed locally. Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18894#pullrequestreview-2015334437

From cjplummer at openjdk.org  Mon Apr 22 19:56:27 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 22 Apr 2024 19:56:27 GMT
Subject: RFR: 8330155: Serial: Remove TenuredSpace
In-Reply-To: <akIgBAk_kI6GQ8orQgn1h1KDPcs1H2AZlq9EHgVLYWI=.e6363e84-1349-464a-98c9-232ba97c2758@github.com>
References: <akIgBAk_kI6GQ8orQgn1h1KDPcs1H2AZlq9EHgVLYWI=.e6363e84-1349-464a-98c9-232ba97c2758@github.com>
Message-ID: <NxGpRiVsg8Iz8t8urdjfOsDDnnr9crwRmGmX9EmzL4A=.4037484e-305f-4e68-aa65-aed80763b556@github.com>

On Mon, 22 Apr 2024 16:24:06 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch removes the class `TenuredSpace` and adjusts its usages. After removing `TenuredSpace`, the file `space.inline.hpp` is empty, so I remove this file and change the included header file to `space.hpp`.
> 
> The test `make test-tier1_gc` passed locally. Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

SA changes look good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18894#pullrequestreview-2015689218

From coleenp at openjdk.org  Mon Apr 22 21:38:28 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 22 Apr 2024 21:38:28 GMT
Subject: RFR: 8330388: Remove invokedynamic cache index encoding [v2]
In-Reply-To: <Jn3By48SnhRcPCQZunBMhOSpnrwx3VwkX9YvP9MPZ1g=.738766a7-4c68-4f7b-b252-1a4204c744f2@github.com>
References: <QbD7B30aa0z4LsbSTZbxGQVFUu5yxpCFiiNZTdskonY=.eaca60d3-73fc-4302-8aa0-c06e5b855cfd@github.com>
 <Jn3By48SnhRcPCQZunBMhOSpnrwx3VwkX9YvP9MPZ1g=.738766a7-4c68-4f7b-b252-1a4204c744f2@github.com>
Message-ID: <GYeQO3jarw3ltsRFS61PRSAh6mVoF4YhljoJNJrAw-w=.4bdd2074-0c75-492e-868b-cecb6c9bb91c@github.com>

On Thu, 18 Apr 2024 16:22:31 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> Before [JDK-8307190](https://bugs.openjdk.org/browse/JDK-8307190), [JDK-8309673](https://bugs.openjdk.org/browse/JDK-8309673), and [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995), invokedynamic operands needed to be rewritten to encoded values to better distinguish indy entries from other cp cache entries. The above changes now distinguish between entries with `to_cp_index()` using the bytecode, which is now propagated by the callers.
>> 
>> The encoding flips the bits of the index so the encoded index is always negative, leading to access errors if there is no matching decode call. These calls are removed with some methods adjusted to distinguish between indices with the bytecode. Verified with tier 1-5 tests. The changes show no issues when tested against libgraal.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Dean and Gilles comments

Still good!

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18819#pullrequestreview-2015844122

From dholmes at openjdk.org  Tue Apr 23 04:56:27 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 23 Apr 2024 04:56:27 GMT
Subject: RFR: 8329113: Deprecate -XX:+UseNotificationThread
In-Reply-To: <tKZ7tFJCnbAHubp3yBKmZI35IjOO7Y2UEbPzD7u7s5M=.5dc6c55c-33b4-4d4e-b776-568bcbc42c2f@github.com>
References: <QhEOdTwHfQbI3r9HemyTHZccwxKaoeGonhXlEnlm33Y=.6ab02510-6fc7-47d5-a3f9-03cb93205b59@github.com>
 <pClTKZ6y2QOM1kx2R59R-ueKKYT2pJv_FlS1Zyp-qsk=.e41ecf38-f656-43be-82fd-6bf87dfd088a@github.com>
 <tKZ7tFJCnbAHubp3yBKmZI35IjOO7Y2UEbPzD7u7s5M=.5dc6c55c-33b4-4d4e-b776-568bcbc42c2f@github.com>
Message-ID: <1ToS_W3IviBX0qh4OXuplcD6Dwmm7von0uPBzg-KW9c=.31205bc7-e150-4d55-ac52-26c6563eb3cd@github.com>

On Fri, 19 Apr 2024 18:07:00 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> > Have you looked for any tests that are using this option?
> 
> No tests use the option

Well they do but it is done via a task definition in hs-tier5-svc.js.

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

PR Comment: https://git.openjdk.org/jdk/pull/18852#issuecomment-2071406176

From dholmes at openjdk.org  Tue Apr 23 04:59:28 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 23 Apr 2024 04:59:28 GMT
Subject: RFR: 8329113: Deprecate -XX:+UseNotificationThread
In-Reply-To: <QhEOdTwHfQbI3r9HemyTHZccwxKaoeGonhXlEnlm33Y=.6ab02510-6fc7-47d5-a3f9-03cb93205b59@github.com>
References: <QhEOdTwHfQbI3r9HemyTHZccwxKaoeGonhXlEnlm33Y=.6ab02510-6fc7-47d5-a3f9-03cb93205b59@github.com>
Message-ID: <7qXizkTDxwxixKvQTi8i5AFgqhucp11k3zj5_5FJYgY=.fd9951b9-4042-46cc-bacc-a4d4269774c1@github.com>

On Fri, 19 Apr 2024 01:16:46 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix deprecates -XX:+UseNotificationThread VM option
> 
> Testing: tier1-3,hs-tier5-svc

Changes look good but please ensure tier5 svc tests pass with the warning enabled

EDIT: Ah I see you already indicated they did - thanks

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18852#pullrequestreview-2016235776

From tschatzl at openjdk.org  Tue Apr 23 09:44:29 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 23 Apr 2024 09:44:29 GMT
Subject: RFR: 8330155: Serial: Remove TenuredSpace
In-Reply-To: <akIgBAk_kI6GQ8orQgn1h1KDPcs1H2AZlq9EHgVLYWI=.e6363e84-1349-464a-98c9-232ba97c2758@github.com>
References: <akIgBAk_kI6GQ8orQgn1h1KDPcs1H2AZlq9EHgVLYWI=.e6363e84-1349-464a-98c9-232ba97c2758@github.com>
Message-ID: <1ZzvLCjrIROXngFcoJgvFqRUKp7ZIqi2r-WmaMSFt_A=.ba452467-a067-4177-9acf-4bee62658f26@github.com>

On Mon, 22 Apr 2024 16:24:06 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch removes the class `TenuredSpace` and adjusts its usages. After removing `TenuredSpace`, the file `space.inline.hpp` is empty, so I remove this file and change the included header file to `space.hpp`.
> 
> The test `make test-tier1_gc` passed locally. Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18894#pullrequestreview-2016759032

From snazarki at openjdk.org  Tue Apr 23 10:51:28 2024
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Tue, 23 Apr 2024 10:51:28 GMT
Subject: RFR: 8330171: Lazy W^X switch implementation
In-Reply-To: <DGjOTJjWNyRdiUDzupUmGBzS6N7anW3ECzYAtjRUZOQ=.310e6e2a-a387-407b-a293-a14381c04980@github.com>
References: <9eymaXovxUNFdkAkzojFQP5trwl_yyY0jE2GzcMEjR4=.02ee2ef9-c476-4c7c-9e4a-e021425c38bc@github.com>
 <DGjOTJjWNyRdiUDzupUmGBzS6N7anW3ECzYAtjRUZOQ=.310e6e2a-a387-407b-a293-a14381c04980@github.com>
Message-ID: <VViOgQRmw8OsRtS1ik_5cTXBWImuvU8IxST5BlLcrNc=.6624ce84-7e3b-46cf-ba39-f71ad3e221a0@github.com>

On Fri, 19 Apr 2024 07:44:17 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> An alternative for preemptively switching the W^X thread mode on macOS with an AArch64 CPU. This implementation triggers the switch in response to the SIGBUS signal if the *si_addr* belongs to the CodeCache area. With this approach, it is now feasible to eliminate all WX guards and avoid potentially costly operations. However, no significant improvement or degradation in performance has been observed.  Additionally, considering the issue with AsyncGetCallTrace, the patched JVM has been successfully operated with [asgct_bottom](https://github.com/parttimenerd/asgct_bottom) and [async-profiler](https://github.com/async-profiler/async-profiler). 
>> 
>> Additional testing:
>> - [x] MacOS AArch64 server fastdebug *gtets*
>> - [ ] MacOS AArch64 server fastdebug *jtreg:hotspot:tier4*
>> - [ ] Benchmarking
>> 
>> @apangin and @parttimenerd could you please check the patch on your scenarios??
>
> What about granting `WXWrite` only if the current thread is in `_thread_in_vm`?
> That would be more restrictive and roughly equivalent how it currently works. Likely there are some places then that should be granted `WXWrite` eagerly because they need `WXWrite` without `_thread_in_vm`. E.g. the JIT compiler threads should have `WXWrite` and never `WXExec` (I assume) which should be checked in the signal handler.

The patch doesn't protect against native agents, as this is obviously impossible. The current code doesn't do that either.  For the bytecode, it doesn't prevent the attacker from abusing unsafe api to modify code cache. However unsafe functions are already considered "safe" and we proactively enable WXWrite as well as move thread to `_thread_in_vm` state (@reinrich). JITed code can't write to the cache either with or without the patch.  

I totally get the sense of loss of security. But is this really the case?

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

PR Comment: https://git.openjdk.org/jdk/pull/18762#issuecomment-2071988941

From coleenp at openjdk.org  Tue Apr 23 11:50:29 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 23 Apr 2024 11:50:29 GMT
Subject: RFR: 8329113: Deprecate -XX:+UseNotificationThread
In-Reply-To: <QhEOdTwHfQbI3r9HemyTHZccwxKaoeGonhXlEnlm33Y=.6ab02510-6fc7-47d5-a3f9-03cb93205b59@github.com>
References: <QhEOdTwHfQbI3r9HemyTHZccwxKaoeGonhXlEnlm33Y=.6ab02510-6fc7-47d5-a3f9-03cb93205b59@github.com>
Message-ID: <MAPweZoT0K73bD5nwWUpymbX86E2iEdK1sFPKNhVwhI=.7f8d1c3f-8ca9-43e0-bc7b-395fc89bbe78@github.com>

On Fri, 19 Apr 2024 01:16:46 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix deprecates -XX:+UseNotificationThread VM option
> 
> Testing: tier1-3,hs-tier5-svc

Looks good.  Thank you for doing this.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18852#pullrequestreview-2017009355

From jwaters at openjdk.org  Tue Apr 23 14:00:38 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 23 Apr 2024 14:00:38 GMT
Subject: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for hsdis
Message-ID: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>

WIP

This changeset contains hsdis for Windows/gcc Port. It supports both the binutils and capstone backends, though the LLVM backend is left out due to compatibility issues encountered during the build. Currently, which gcc distributions are supported is still to be clarified, as several, ranging from Cygwin, to MinGW64, to the gcc subsystems from MSYS2. For this reason, the build system hack in place at the moment to compile the binutils backend on Windows is still left in place, for now.

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

Commit messages:
 - Implementation of hsdis for 8288293: Windows/gcc Port

Changes: https://git.openjdk.org/jdk/pull/18915/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18915&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330988
  Stats: 347 lines in 28 files changed: 161 ins; 22 del; 164 mod
  Patch: https://git.openjdk.org/jdk/pull/18915.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18915/head:pull/18915

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

From ihse at openjdk.org  Tue Apr 23 14:28:31 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 23 Apr 2024 14:28:31 GMT
Subject: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for
 hsdis
In-Reply-To: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
References: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
Message-ID: <UtwNIMCOiQMIW52vi4FNfA6Z0r7maxUMA0eOrVmQ2QM=.b0810730-dc5d-4bee-aae3-96b2c8b1c399@github.com>

On Tue, 23 Apr 2024 13:56:32 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> WIP
> 
> This changeset contains hsdis for Windows/gcc Port. It supports both the binutils and capstone backends, though the LLVM backend is left out due to compatibility issues encountered during the build. Currently, which gcc distributions are supported is still to be clarified, as several, ranging from Cygwin, to MinGW64, to the gcc subsystems from MSYS2. For this reason, the build system hack in place at the moment to compile the binutils backend on Windows is still left in place, for now.

There's a huge amount of changes for just hsdis... You might have to separate out the infrastructure changes that seem to amount to most of the changes here.

This is going to take me a while to get through.

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

PR Comment: https://git.openjdk.org/jdk/pull/18915#issuecomment-2072458273

From jwaters at openjdk.org  Tue Apr 23 14:34:27 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 23 Apr 2024 14:34:27 GMT
Subject: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for
 hsdis
In-Reply-To: <UtwNIMCOiQMIW52vi4FNfA6Z0r7maxUMA0eOrVmQ2QM=.b0810730-dc5d-4bee-aae3-96b2c8b1c399@github.com>
References: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
 <UtwNIMCOiQMIW52vi4FNfA6Z0r7maxUMA0eOrVmQ2QM=.b0810730-dc5d-4bee-aae3-96b2c8b1c399@github.com>
Message-ID: <gC3MXf8nowx4TzNB4qHTC-fUoC-VTGMRn7EkZqsOLS0=.ab83679d-9b6c-4b86-ae74-3c0c05a44631@github.com>

On Tue, 23 Apr 2024 14:25:22 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> There's a huge amount of changes for just hsdis... You might have to separate out the infrastructure changes that seem to amount to most of the changes here.
> 
> This is going to take me a while to get through.

Sorry, it's still a WIP, and I believe something broke and scattered changes from one of my other local branches into this current changeset

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

PR Comment: https://git.openjdk.org/jdk/pull/18915#issuecomment-2072483937

From matsaave at openjdk.org  Tue Apr 23 15:05:33 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 23 Apr 2024 15:05:33 GMT
Subject: RFR: 8330388: Remove invokedynamic cache index encoding
In-Reply-To: <-5i_BDguO1qWOP0GnYK4pTeMMW4IhlV3LkqLPFs4vAw=.060c849a-de1a-4888-943e-80b9ed4eecf2@github.com>
References: <QbD7B30aa0z4LsbSTZbxGQVFUu5yxpCFiiNZTdskonY=.eaca60d3-73fc-4302-8aa0-c06e5b855cfd@github.com>
 <-5i_BDguO1qWOP0GnYK4pTeMMW4IhlV3LkqLPFs4vAw=.060c849a-de1a-4888-943e-80b9ed4eecf2@github.com>
Message-ID: <n7Ap3zdZ4JYmgRcDnJivIwEH6OUEW6rehQ9jewwM0N8=.138021b8-9c5d-4f03-8366-b03b65e0a69e@github.com>

On Wed, 17 Apr 2024 22:48:16 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Before [JDK-8307190](https://bugs.openjdk.org/browse/JDK-8307190), [JDK-8309673](https://bugs.openjdk.org/browse/JDK-8309673), and [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995), invokedynamic operands needed to be rewritten to encoded values to better distinguish indy entries from other cp cache entries. The above changes now distinguish between entries with `to_cp_index()` using the bytecode, which is now propagated by the callers.
>> 
>> The encoding flips the bits of the index so the encoded index is always negative, leading to access errors if there is no matching decode call. These calls are removed with some methods adjusted to distinguish between indices with the bytecode. Verified with tier 1-5 tests. The changes show no issues when tested against libgraal.
>
> Did you consider minimizing changes by leaving decode_invokedynamic_index/encode_invokedynamic_index calls in place, but having the implementations not change the value?

Thanks for the reviews @dean-long @gilles-duboscq @coleenp and @plummercj!

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

PR Comment: https://git.openjdk.org/jdk/pull/18819#issuecomment-2072603376

From matsaave at openjdk.org  Tue Apr 23 15:05:34 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 23 Apr 2024 15:05:34 GMT
Subject: Integrated: 8330388: Remove invokedynamic cache index encoding
In-Reply-To: <QbD7B30aa0z4LsbSTZbxGQVFUu5yxpCFiiNZTdskonY=.eaca60d3-73fc-4302-8aa0-c06e5b855cfd@github.com>
References: <QbD7B30aa0z4LsbSTZbxGQVFUu5yxpCFiiNZTdskonY=.eaca60d3-73fc-4302-8aa0-c06e5b855cfd@github.com>
Message-ID: <xOEQPoZPI8N49qGI_rfcINsk7Ih7EQMQ8_nufeN8JTU=.f1285bb8-5c69-467e-9450-f9a5d45c366c@github.com>

On Wed, 17 Apr 2024 15:26:52 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> Before [JDK-8307190](https://bugs.openjdk.org/browse/JDK-8307190), [JDK-8309673](https://bugs.openjdk.org/browse/JDK-8309673), and [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995), invokedynamic operands needed to be rewritten to encoded values to better distinguish indy entries from other cp cache entries. The above changes now distinguish between entries with `to_cp_index()` using the bytecode, which is now propagated by the callers.
> 
> The encoding flips the bits of the index so the encoded index is always negative, leading to access errors if there is no matching decode call. These calls are removed with some methods adjusted to distinguish between indices with the bytecode. Verified with tier 1-5 tests. The changes show no issues when tested against libgraal.

This pull request has now been integrated.

Changeset: 383fe6ea
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/383fe6eaab423a1218c9915362f691472e3773e7
Stats:     225 lines in 37 files changed: 15 ins; 137 del; 73 mod

8330388: Remove invokedynamic cache index encoding

Reviewed-by: cjplummer, dlong, coleenp

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

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

From aph at openjdk.org  Tue Apr 23 15:13:29 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 23 Apr 2024 15:13:29 GMT
Subject: RFR: 8330171: Lazy W^X switch implementation
In-Reply-To: <DGjOTJjWNyRdiUDzupUmGBzS6N7anW3ECzYAtjRUZOQ=.310e6e2a-a387-407b-a293-a14381c04980@github.com>
References: <9eymaXovxUNFdkAkzojFQP5trwl_yyY0jE2GzcMEjR4=.02ee2ef9-c476-4c7c-9e4a-e021425c38bc@github.com>
 <DGjOTJjWNyRdiUDzupUmGBzS6N7anW3ECzYAtjRUZOQ=.310e6e2a-a387-407b-a293-a14381c04980@github.com>
Message-ID: <Ypy3borKtPa_pBCqZKQnF6ULfIuw93R1YDBQhaDUl4o=.aa7eef47-d3d2-48ef-a448-75d400ffbb28@github.com>

On Fri, 19 Apr 2024 07:44:17 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> An alternative for preemptively switching the W^X thread mode on macOS with an AArch64 CPU. This implementation triggers the switch in response to the SIGBUS signal if the *si_addr* belongs to the CodeCache area. With this approach, it is now feasible to eliminate all WX guards and avoid potentially costly operations. However, no significant improvement or degradation in performance has been observed.  Additionally, considering the issue with AsyncGetCallTrace, the patched JVM has been successfully operated with [asgct_bottom](https://github.com/parttimenerd/asgct_bottom) and [async-profiler](https://github.com/async-profiler/async-profiler). 
>> 
>> Additional testing:
>> - [x] MacOS AArch64 server fastdebug *gtets*
>> - [ ] MacOS AArch64 server fastdebug *jtreg:hotspot:tier4*
>> - [ ] Benchmarking
>> 
>> @apangin and @parttimenerd could you please check the patch on your scenarios??
>
> What about granting `WXWrite` only if the current thread is in `_thread_in_vm`?
> That would be more restrictive and roughly equivalent how it currently works. Likely there are some places then that should be granted `WXWrite` eagerly because they need `WXWrite` without `_thread_in_vm`. E.g. the JIT compiler threads should have `WXWrite` and never `WXExec` (I assume) which should be checked in the signal handler.

> The patch doesn't protect against native agents, as this is obviously impossible. The current code doesn't do that either. For the bytecode, it doesn't prevent the attacker from abusing unsafe api to modify code cache. However unsafe functions are already considered "safe" and we proactively enable WXWrite as well as move thread to `_thread_in_vm` state (@reinrich). JITed code can't write to the cache either with or without the patch.
> 
> I totally get the sense of loss of security. But is this really the case?

I think it is. W^X is intended (amongst other things) to protect against the use of gadgets, from buffer overflow exploits in non-java code to ROP programming. At present, in order to generate code and execute it, you first have to be able to make the JIT code writable, then write the code, then make it executable. then jump to the code. And the exploit writer might have to do some or all of this by finding gadgets. If we were to merge this patch then all the attacker would have to do is write code to memory and find a way to jump to it, and the automatic switch-on-segfault in this patch would do the all the work the attacker needs.

It makes far more sense to tag those places that actually need to change W^X access, and only switch there.

You could argue that any switching of W^X on a write to code space, then switching it back on jumping (or returning) to Java code, even what we already do, is effectively the same thing. Kinda, but it's not on just any attempt to write to code space or any attempt to jump into code, it's at the places we choose, and we can be careful to limit those places.

But surely the JDK is not the most vulnerable part of the stack anyway? I'd agree with that, of course, but I don't think that's sufficient reason to decide to bypass an OS security mechanism.

We are trying to reduce the size of the attack surface.

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

PR Comment: https://git.openjdk.org/jdk/pull/18762#issuecomment-2072639243

From gli at openjdk.org  Tue Apr 23 16:04:37 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Tue, 23 Apr 2024 16:04:37 GMT
Subject: RFR: 8330155: Serial: Remove TenuredSpace [v2]
In-Reply-To: <akIgBAk_kI6GQ8orQgn1h1KDPcs1H2AZlq9EHgVLYWI=.e6363e84-1349-464a-98c9-232ba97c2758@github.com>
References: <akIgBAk_kI6GQ8orQgn1h1KDPcs1H2AZlq9EHgVLYWI=.e6363e84-1349-464a-98c9-232ba97c2758@github.com>
Message-ID: <IKpXYKw7Ei_x1eEhiUVJEcX9cWfrzFZUtfrs2mhBxTQ=.602f3041-d61c-486d-9999-3e9312639ae5@github.com>

> Hi all,
> 
> This patch removes the class `TenuredSpace` and adjusts its usages. After removing `TenuredSpace`, the file `space.inline.hpp` is empty, so I remove this file and change the included header file to `space.hpp`.
> 
> The test `make test-tier1_gc` passed locally. Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Remove file.
 - Merge branch 'master' into REMOVE_TENURED_SPACE
   
   # Conflicts:
   #	src/hotspot/share/gc/serial/defNewGeneration.inline.hpp
 - JDK-8330155

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

Changes: https://git.openjdk.org/jdk/pull/18894/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18894&range=01
  Stats: 161 lines in 20 files changed: 10 ins; 127 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/18894.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18894/head:pull/18894

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

From gli at openjdk.org  Tue Apr 23 17:22:41 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Tue, 23 Apr 2024 17:22:41 GMT
Subject: RFR: 8330155: Serial: Remove TenuredSpace [v3]
In-Reply-To: <akIgBAk_kI6GQ8orQgn1h1KDPcs1H2AZlq9EHgVLYWI=.e6363e84-1349-464a-98c9-232ba97c2758@github.com>
References: <akIgBAk_kI6GQ8orQgn1h1KDPcs1H2AZlq9EHgVLYWI=.e6363e84-1349-464a-98c9-232ba97c2758@github.com>
Message-ID: <eCWiw2FKdSBPI5TBJbZwTgg2qSlR3UnnYwo-BHgrSvg=.4a3cd2f5-f3a7-485e-8954-f69b14da602c@github.com>

> Hi all,
> 
> This patch removes the class `TenuredSpace` and adjusts its usages. After removing `TenuredSpace`, the file `space.inline.hpp` is empty, so I remove this file and change the included header file to `space.hpp`.
> 
> The test `make test-tier1_gc` passed locally. Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Fix included header file error after merging master.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18894/files
  - new: https://git.openjdk.org/jdk/pull/18894/files/0796e0b4..5478742c

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

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

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

From gli at openjdk.org  Tue Apr 23 17:33:31 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Tue, 23 Apr 2024 17:33:31 GMT
Subject: RFR: 8330155: Serial: Remove TenuredSpace [v3]
In-Reply-To: <eCWiw2FKdSBPI5TBJbZwTgg2qSlR3UnnYwo-BHgrSvg=.4a3cd2f5-f3a7-485e-8954-f69b14da602c@github.com>
References: <akIgBAk_kI6GQ8orQgn1h1KDPcs1H2AZlq9EHgVLYWI=.e6363e84-1349-464a-98c9-232ba97c2758@github.com>
 <eCWiw2FKdSBPI5TBJbZwTgg2qSlR3UnnYwo-BHgrSvg=.4a3cd2f5-f3a7-485e-8954-f69b14da602c@github.com>
Message-ID: <13XcdYfz-Qdc4pOKtZK0IIYJM7xrCFuiM4LSpgQ2JhE=.26e5fa50-0d25-4e3e-b603-4299cf837614@github.com>

On Tue, 23 Apr 2024 17:22:41 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch removes the class `TenuredSpace` and adjusts its usages. After removing `TenuredSpace`, the file `space.inline.hpp` is empty, so I remove this file and change the included header file to `space.hpp`.
>> 
>> The test `make test-tier1_gc` passed locally. Thanks for taking the time to review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix included header file error after merging master.

I merged the master branch in order to solve the file conflict and added the missed header file after merging. Please take a look at the newest code.

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

PR Comment: https://git.openjdk.org/jdk/pull/18894#issuecomment-2072993947

From sspitsyn at openjdk.org  Tue Apr 23 18:13:31 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 23 Apr 2024 18:13:31 GMT
Subject: RFR: 8328741:
 serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java failed with
 unexpected owner [v4]
In-Reply-To: <bqvxPNF1XX1QRd3U5M1GZXeE-5ddx0s6ukIay9RTB_M=.7fb03a0d-b931-4ee4-ba61-1cabfd4b3cd8@github.com>
References: <qXonY64Tq0lRSrpqGH86L7qGC1lpTmNZtQk54HFbHG4=.08c6864e-b84b-48ff-90e3-4d0768b42c45@github.com>
 <bqvxPNF1XX1QRd3U5M1GZXeE-5ddx0s6ukIay9RTB_M=.7fb03a0d-b931-4ee4-ba61-1cabfd4b3cd8@github.com>
Message-ID: <Cjq3P91MdmvJ0KSHxh521UaAVanqVrwr4VkFDbZQpoY=.113a38a4-3675-40cd-9276-5c5617e396d1@github.com>

On Thu, 18 Apr 2024 21:56:09 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is the test issue. The `WaitingPT3` thread posted the `MonitorWait` event but has not released the `lockCheck` monitor yet. It has been fixed to wait for each `WaitingTask` thread to really reach the `WAITING` state. The same approach is used for `EnteringTask` threads. It has been fixed to wait for each `EnteringTask` thread to reach the `BLOCKED_ON_MONITOR` state.
>> 
>> Testing:
>>  - Reran the test `serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java` locally
>>  - TBD: submit the mach5 tiers 1-6 as well
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: tweak in wait_for_state func to allow exp_state bit mask

Ping!! Need one more review, please.

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

PR Comment: https://git.openjdk.org/jdk/pull/18778#issuecomment-2073073521

From sspitsyn at openjdk.org  Tue Apr 23 18:14:28 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 23 Apr 2024 18:14:28 GMT
Subject: RFR: 8330303: Crash: assert(_target_jt == nullptr ||
 _target_jt->vthread() == target_h()) failed
In-Reply-To: <s2XOP447huiEO4ph2kU-LkemkBxloUBcbcdtYOOnCpo=.98c07b6f-9e71-4e66-ac3d-7eab1c805dfc@github.com>
References: <s2XOP447huiEO4ph2kU-LkemkBxloUBcbcdtYOOnCpo=.98c07b6f-9e71-4e66-ac3d-7eab1c805dfc@github.com>
Message-ID: <fB5ezn7cRjd789wkAPnB9Cl99nqgub-XW3LbtKyrlwQ=.e073d9bc-589e-4101-a954-69b680a25298@github.com>

On Wed, 17 Apr 2024 00:29:52 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This is a simple fix of three similar asserts.
> The `_target_jt->jvmti_vthread()` has to be used instead of `_target_jt->vthread()`. 
> The `_target_jt->vthread()` can be outdated in some specific contexts as shown in the `hs_err` stack trace.
> 
> I've seen similar issue and already fixed it in this fragment of code:
> 
> class GetCurrentLocationClosure : public JvmtiUnitedHandshakeClosure {
>   . . .
>   void do_vthread(Handle target_h) {
>     assert(_target_jt == nullptr || !_target_jt->is_exiting(), "sanity check");
>     // use jvmti_vthread() as vthread() can be outdated
>     assert(_target_jt == nullptr || _target_jt->jvmti_vthread() == target_h(), "sanity check");
>     . . .
> 
> The issue above was fixed by replacing `_target_jt->vthread()` with `_target_jt->jvmti_vthread()`.
> 
> There are three places which need to be fixed the same way:
>  - `GetSingleStackTraceClosure::do_vthread(Handle target_h)`
>  - `SetForceEarlyReturn::do_vthread(Handle target_h)`
>  - `UpdateForPopTopFrameClosure::do_vthread(Handle target_h)`
> 
> Testing:
>  - Run mach5 tiers 1-6

Ping!! Still need this reviewed.

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

PR Comment: https://git.openjdk.org/jdk/pull/18806#issuecomment-2073075364

From amenkov at openjdk.org  Tue Apr 23 19:05:40 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 23 Apr 2024 19:05:40 GMT
Subject: RFR: 8329113: Deprecate -XX:+UseNotificationThread [v2]
In-Reply-To: <QhEOdTwHfQbI3r9HemyTHZccwxKaoeGonhXlEnlm33Y=.6ab02510-6fc7-47d5-a3f9-03cb93205b59@github.com>
References: <QhEOdTwHfQbI3r9HemyTHZccwxKaoeGonhXlEnlm33Y=.6ab02510-6fc7-47d5-a3f9-03cb93205b59@github.com>
Message-ID: <pnz5m2RGogV7XypLJoKvqgs6pAkyKeURnE04CEJnJE4=.9b180627-3dfa-480c-b2c1-ce4f229af0eb@github.com>

> The fix deprecates -XX:+UseNotificationThread VM option
> 
> Testing: tier1-3,hs-tier5-svc

Alex Menkov 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 deprecate_notif_thread
 - fix

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

Changes: https://git.openjdk.org/jdk/pull/18852/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18852&range=01
  Stats: 3 lines in 3 files changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/18852.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18852/head:pull/18852

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

From pchilanomate at openjdk.org  Tue Apr 23 19:28:30 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 23 Apr 2024 19:28:30 GMT
Subject: RFR: 8330303: Crash: assert(_target_jt == nullptr ||
 _target_jt->vthread() == target_h()) failed
In-Reply-To: <s2XOP447huiEO4ph2kU-LkemkBxloUBcbcdtYOOnCpo=.98c07b6f-9e71-4e66-ac3d-7eab1c805dfc@github.com>
References: <s2XOP447huiEO4ph2kU-LkemkBxloUBcbcdtYOOnCpo=.98c07b6f-9e71-4e66-ac3d-7eab1c805dfc@github.com>
Message-ID: <OSk-ZMdZFMZ7w9pmohLK2hDDekqiV_M62ZIiRn7fy0U=.8de1d57c-7750-4db1-b0d6-6fb4ee9d5802@github.com>

On Wed, 17 Apr 2024 00:29:52 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This is a simple fix of three similar asserts.
> The `_target_jt->jvmti_vthread()` has to be used instead of `_target_jt->vthread()`. 
> The `_target_jt->vthread()` can be outdated in some specific contexts as shown in the `hs_err` stack trace.
> 
> I've seen similar issue and already fixed it in this fragment of code:
> 
> class GetCurrentLocationClosure : public JvmtiUnitedHandshakeClosure {
>   . . .
>   void do_vthread(Handle target_h) {
>     assert(_target_jt == nullptr || !_target_jt->is_exiting(), "sanity check");
>     // use jvmti_vthread() as vthread() can be outdated
>     assert(_target_jt == nullptr || _target_jt->jvmti_vthread() == target_h(), "sanity check");
>     . . .
> 
> The issue above was fixed by replacing `_target_jt->vthread()` with `_target_jt->jvmti_vthread()`.
> 
> There are three places which need to be fixed the same way:
>  - `GetSingleStackTraceClosure::do_vthread(Handle target_h)`
>  - `SetForceEarlyReturn::do_vthread(Handle target_h)`
>  - `UpdateForPopTopFrameClosure::do_vthread(Handle target_h)`
> 
> Testing:
>  - Run mach5 tiers 1-6

Looks good. Just small suggestion.

Thanks,
Patricio

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

> 2077: void
> 2078: GetSingleStackTraceClosure::do_vthread(Handle target_h) {
> 2079:   // use jvmti_vthread() as vthread() can be outdated

The only reason I can see of why just using vthread() doesn't work is because of the case where we are in a temporary switch to carrier thread. So maybe change comment to be: "use jvmti_vthread() instead of vthread() as target could?have temporary changed identity to carrier thread (see VirtualThread.switchToCarrierThread)". Same in the other places.

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

Marked as reviewed by pchilanomate (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18806#pullrequestreview-2018092388
PR Review Comment: https://git.openjdk.org/jdk/pull/18806#discussion_r1576768011

From jjg at openjdk.org  Tue Apr 23 20:26:57 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 23 Apr 2024 20:26:57 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v7]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <RHregxT5ye-XTQEWzPqLPVZXgm2Id82FV--QqNLAJMc=.4c5c4e64-3a6c-438f-a877-e6f9689986fd@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge with upstream/master
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - Merge with upstream/master
 - update test
 - improve handling of ignorable doc comments
   suppress warning when building test code
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - call `saveDanglingDocComments` for local variable declarations
 - adjust call for `saveDanglingDocComments` for enum members
 - JDK-8303689: javac -Xlint could/should report on "dangling" doc comments

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

Changes: https://git.openjdk.org/jdk/pull/18527/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18527&range=06
  Stats: 485 lines in 59 files changed: 387 ins; 3 del; 95 mod
  Patch: https://git.openjdk.org/jdk/pull/18527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18527/head:pull/18527

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

From amenkov at openjdk.org  Tue Apr 23 20:40:31 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 23 Apr 2024 20:40:31 GMT
Subject: Integrated: 8329113: Deprecate -XX:+UseNotificationThread
In-Reply-To: <QhEOdTwHfQbI3r9HemyTHZccwxKaoeGonhXlEnlm33Y=.6ab02510-6fc7-47d5-a3f9-03cb93205b59@github.com>
References: <QhEOdTwHfQbI3r9HemyTHZccwxKaoeGonhXlEnlm33Y=.6ab02510-6fc7-47d5-a3f9-03cb93205b59@github.com>
Message-ID: <gzQUy0rZmh2sAQjgXOdgkPaSdoTme1M-87sAhJCaGPQ=.accd929b-019f-432d-bd78-e7d43aa71337@github.com>

On Fri, 19 Apr 2024 01:16:46 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix deprecates -XX:+UseNotificationThread VM option
> 
> Testing: tier1-3,hs-tier5-svc

This pull request has now been integrated.

Changeset: 25551662
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2555166247230497453503318ccbf4dd4f047193
Stats:     3 lines in 3 files changed: 2 ins; 0 del; 1 mod

8329113: Deprecate -XX:+UseNotificationThread

Reviewed-by: dcubed, dholmes, coleenp

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

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

From cjplummer at openjdk.org  Tue Apr 23 20:50:28 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 23 Apr 2024 20:50:28 GMT
Subject: RFR: 8328741:
 serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java failed with
 unexpected owner [v4]
In-Reply-To: <bqvxPNF1XX1QRd3U5M1GZXeE-5ddx0s6ukIay9RTB_M=.7fb03a0d-b931-4ee4-ba61-1cabfd4b3cd8@github.com>
References: <qXonY64Tq0lRSrpqGH86L7qGC1lpTmNZtQk54HFbHG4=.08c6864e-b84b-48ff-90e3-4d0768b42c45@github.com>
 <bqvxPNF1XX1QRd3U5M1GZXeE-5ddx0s6ukIay9RTB_M=.7fb03a0d-b931-4ee4-ba61-1cabfd4b3cd8@github.com>
Message-ID: <dkdDyq2k0-0JBKznUck1wEChT2V6x2u2hn7FSUejqtE=.cbccb132-95ba-429c-95e3-4fd9ed335cdc@github.com>

On Thu, 18 Apr 2024 21:56:09 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is the test issue. The `WaitingPT3` thread posted the `MonitorWait` event but has not released the `lockCheck` monitor yet. It has been fixed to wait for each `WaitingTask` thread to really reach the `WAITING` state. The same approach is used for `EnteringTask` threads. It has been fixed to wait for each `EnteringTask` thread to reach the `BLOCKED_ON_MONITOR` state.
>> 
>> Testing:
>>  - Reran the test `serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java` locally
>>  - TBD: submit the mach5 tiers 1-6 as well
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: tweak in wait_for_state func to allow exp_state bit mask

Changes requested by cjplummer (Reviewer).

test/hotspot/jtreg/serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java line 58:

> 56:     native static int setTestedMonitor(Object monitor);
> 57:     native static void ensureBlockedOnEnter(Thread thread);
> 58:     native static void ensureWaitsToBeNotified(Thread thread);

This should be named "Waiting" instead of "Waits".

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

PR Review: https://git.openjdk.org/jdk/pull/18778#pullrequestreview-2018273130
PR Review Comment: https://git.openjdk.org/jdk/pull/18778#discussion_r1576875339

From cjplummer at openjdk.org  Tue Apr 23 20:53:28 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 23 Apr 2024 20:53:28 GMT
Subject: RFR: 8330303: Crash: assert(_target_jt == nullptr ||
 _target_jt->vthread() == target_h()) failed
In-Reply-To: <s2XOP447huiEO4ph2kU-LkemkBxloUBcbcdtYOOnCpo=.98c07b6f-9e71-4e66-ac3d-7eab1c805dfc@github.com>
References: <s2XOP447huiEO4ph2kU-LkemkBxloUBcbcdtYOOnCpo=.98c07b6f-9e71-4e66-ac3d-7eab1c805dfc@github.com>
Message-ID: <GMWNz3siReNvNuvnSbivfEthUuGbZ8GQEjtW_QO3WjA=.e7c99e53-ed64-49ae-9cca-b4ef0a013a81@github.com>

On Wed, 17 Apr 2024 00:29:52 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This is a simple fix of three similar asserts.
> The `_target_jt->jvmti_vthread()` has to be used instead of `_target_jt->vthread()`. 
> The `_target_jt->vthread()` can be outdated in some specific contexts as shown in the `hs_err` stack trace.
> 
> I've seen similar issue and already fixed it in this fragment of code:
> 
> class GetCurrentLocationClosure : public JvmtiUnitedHandshakeClosure {
>   . . .
>   void do_vthread(Handle target_h) {
>     assert(_target_jt == nullptr || !_target_jt->is_exiting(), "sanity check");
>     // use jvmti_vthread() as vthread() can be outdated
>     assert(_target_jt == nullptr || _target_jt->jvmti_vthread() == target_h(), "sanity check");
>     . . .
> 
> The issue above was fixed by replacing `_target_jt->vthread()` with `_target_jt->jvmti_vthread()`.
> 
> There are three places which need to be fixed the same way:
>  - `GetSingleStackTraceClosure::do_vthread(Handle target_h)`
>  - `SetForceEarlyReturn::do_vthread(Handle target_h)`
>  - `UpdateForPopTopFrameClosure::do_vthread(Handle target_h)`
> 
> Testing:
>  - Run mach5 tiers 1-6

Looks good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18806#pullrequestreview-2018277846

From sspitsyn at openjdk.org  Tue Apr 23 22:03:31 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 23 Apr 2024 22:03:31 GMT
Subject: RFR: 8328741:
 serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java failed with
 unexpected owner [v4]
In-Reply-To: <dkdDyq2k0-0JBKznUck1wEChT2V6x2u2hn7FSUejqtE=.cbccb132-95ba-429c-95e3-4fd9ed335cdc@github.com>
References: <qXonY64Tq0lRSrpqGH86L7qGC1lpTmNZtQk54HFbHG4=.08c6864e-b84b-48ff-90e3-4d0768b42c45@github.com>
 <bqvxPNF1XX1QRd3U5M1GZXeE-5ddx0s6ukIay9RTB_M=.7fb03a0d-b931-4ee4-ba61-1cabfd4b3cd8@github.com>
 <dkdDyq2k0-0JBKznUck1wEChT2V6x2u2hn7FSUejqtE=.cbccb132-95ba-429c-95e3-4fd9ed335cdc@github.com>
Message-ID: <lji442AdSd22Iub0KLfNDogFidxzeqqKtkXpY2UBAT8=.5ac2670b-a261-4218-bd54-038af41fdeea@github.com>

On Tue, 23 Apr 2024 20:47:34 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: tweak in wait_for_state func to allow exp_state bit mask
>
> test/hotspot/jtreg/serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java line 58:
> 
>> 56:     native static int setTestedMonitor(Object monitor);
>> 57:     native static void ensureBlockedOnEnter(Thread thread);
>> 58:     native static void ensureWaitsToBeNotified(Thread thread);
> 
> This should be named "Waiting" instead of "Waits".

Thank you for the suggestion. Will fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18778#discussion_r1576957455

From sspitsyn at openjdk.org  Tue Apr 23 22:07:28 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 23 Apr 2024 22:07:28 GMT
Subject: RFR: 8330303: Crash: assert(_target_jt == nullptr ||
 _target_jt->vthread() == target_h()) failed
In-Reply-To: <s2XOP447huiEO4ph2kU-LkemkBxloUBcbcdtYOOnCpo=.98c07b6f-9e71-4e66-ac3d-7eab1c805dfc@github.com>
References: <s2XOP447huiEO4ph2kU-LkemkBxloUBcbcdtYOOnCpo=.98c07b6f-9e71-4e66-ac3d-7eab1c805dfc@github.com>
Message-ID: <pBEVHBMlfzpzWRAzJbsUX2zKKrcaHgUOs79G5EAwx0E=.0793ee81-42ff-40fb-90d3-34570e3fa034@github.com>

On Wed, 17 Apr 2024 00:29:52 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This is a simple fix of three similar asserts.
> The `_target_jt->jvmti_vthread()` has to be used instead of `_target_jt->vthread()`. 
> The `_target_jt->vthread()` can be outdated in some specific contexts as shown in the `hs_err` stack trace.
> 
> I've seen similar issue and already fixed it in this fragment of code:
> 
> class GetCurrentLocationClosure : public JvmtiUnitedHandshakeClosure {
>   . . .
>   void do_vthread(Handle target_h) {
>     assert(_target_jt == nullptr || !_target_jt->is_exiting(), "sanity check");
>     // use jvmti_vthread() as vthread() can be outdated
>     assert(_target_jt == nullptr || _target_jt->jvmti_vthread() == target_h(), "sanity check");
>     . . .
> 
> The issue above was fixed by replacing `_target_jt->vthread()` with `_target_jt->jvmti_vthread()`.
> 
> There are three places which need to be fixed the same way:
>  - `GetSingleStackTraceClosure::do_vthread(Handle target_h)`
>  - `SetForceEarlyReturn::do_vthread(Handle target_h)`
>  - `UpdateForPopTopFrameClosure::do_vthread(Handle target_h)`
> 
> Testing:
>  - Run mach5 tiers 1-6

Thank you for review, Patricio and Chris!

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

PR Comment: https://git.openjdk.org/jdk/pull/18806#issuecomment-2073550087

From sspitsyn at openjdk.org  Tue Apr 23 22:07:29 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 23 Apr 2024 22:07:29 GMT
Subject: RFR: 8330303: Crash: assert(_target_jt == nullptr ||
 _target_jt->vthread() == target_h()) failed
In-Reply-To: <OSk-ZMdZFMZ7w9pmohLK2hDDekqiV_M62ZIiRn7fy0U=.8de1d57c-7750-4db1-b0d6-6fb4ee9d5802@github.com>
References: <s2XOP447huiEO4ph2kU-LkemkBxloUBcbcdtYOOnCpo=.98c07b6f-9e71-4e66-ac3d-7eab1c805dfc@github.com>
 <OSk-ZMdZFMZ7w9pmohLK2hDDekqiV_M62ZIiRn7fy0U=.8de1d57c-7750-4db1-b0d6-6fb4ee9d5802@github.com>
Message-ID: <JObS8WAgs9YHjmYDThbeWXOTtf471YUdY0j5bMj9QgE=.55fd9e38-151f-4039-8d26-178534dd7126@github.com>

On Tue, 23 Apr 2024 19:05:38 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is a simple fix of three similar asserts.
>> The `_target_jt->jvmti_vthread()` has to be used instead of `_target_jt->vthread()`. 
>> The `_target_jt->vthread()` can be outdated in some specific contexts as shown in the `hs_err` stack trace.
>> 
>> I've seen similar issue and already fixed it in this fragment of code:
>> 
>> class GetCurrentLocationClosure : public JvmtiUnitedHandshakeClosure {
>>   . . .
>>   void do_vthread(Handle target_h) {
>>     assert(_target_jt == nullptr || !_target_jt->is_exiting(), "sanity check");
>>     // use jvmti_vthread() as vthread() can be outdated
>>     assert(_target_jt == nullptr || _target_jt->jvmti_vthread() == target_h(), "sanity check");
>>     . . .
>> 
>> The issue above was fixed by replacing `_target_jt->vthread()` with `_target_jt->jvmti_vthread()`.
>> 
>> There are three places which need to be fixed the same way:
>>  - `GetSingleStackTraceClosure::do_vthread(Handle target_h)`
>>  - `SetForceEarlyReturn::do_vthread(Handle target_h)`
>>  - `UpdateForPopTopFrameClosure::do_vthread(Handle target_h)`
>> 
>> Testing:
>>  - Run mach5 tiers 1-6
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 2079:
> 
>> 2077: void
>> 2078: GetSingleStackTraceClosure::do_vthread(Handle target_h) {
>> 2079:   // use jvmti_vthread() as vthread() can be outdated
> 
> The only reason I can see of why just using vthread() doesn't work is because of the case where we are in a temporary switch to carrier thread. So maybe change comment to be: "use jvmti_vthread() instead of vthread() as target could?have temporary changed identity to carrier thread (see VirtualThread.switchToCarrierThread)". Same in the other places.

Thank you for the suggestion. Will fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18806#discussion_r1576959637

From lmesnik at openjdk.org  Tue Apr 23 23:43:29 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 23 Apr 2024 23:43:29 GMT
Subject: RFR: 8330303: Crash: assert(_target_jt == nullptr ||
 _target_jt->vthread() == target_h()) failed
In-Reply-To: <s2XOP447huiEO4ph2kU-LkemkBxloUBcbcdtYOOnCpo=.98c07b6f-9e71-4e66-ac3d-7eab1c805dfc@github.com>
References: <s2XOP447huiEO4ph2kU-LkemkBxloUBcbcdtYOOnCpo=.98c07b6f-9e71-4e66-ac3d-7eab1c805dfc@github.com>
Message-ID: <lfsZiL04QHS9E-Vr9mAKipcY6XVZov47jQZYAlqxXkk=.06f1404a-ed71-4ac4-b005-ea9666882f27@github.com>

On Wed, 17 Apr 2024 00:29:52 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This is a simple fix of three similar asserts.
> The `_target_jt->jvmti_vthread()` has to be used instead of `_target_jt->vthread()`. 
> The `_target_jt->vthread()` can be outdated in some specific contexts as shown in the `hs_err` stack trace.
> 
> I've seen similar issue and already fixed it in this fragment of code:
> 
> class GetCurrentLocationClosure : public JvmtiUnitedHandshakeClosure {
>   . . .
>   void do_vthread(Handle target_h) {
>     assert(_target_jt == nullptr || !_target_jt->is_exiting(), "sanity check");
>     // use jvmti_vthread() as vthread() can be outdated
>     assert(_target_jt == nullptr || _target_jt->jvmti_vthread() == target_h(), "sanity check");
>     . . .
> 
> The issue above was fixed by replacing `_target_jt->vthread()` with `_target_jt->jvmti_vthread()`.
> 
> There are three places which need to be fixed the same way:
>  - `GetSingleStackTraceClosure::do_vthread(Handle target_h)`
>  - `SetForceEarlyReturn::do_vthread(Handle target_h)`
>  - `UpdateForPopTopFrameClosure::do_vthread(Handle target_h)`
> 
> Testing:
>  - Run mach5 tiers 1-6

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18806#pullrequestreview-2018506993

From sspitsyn at openjdk.org  Wed Apr 24 00:01:45 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 24 Apr 2024 00:01:45 GMT
Subject: RFR: 8328741:
 serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java failed with
 unexpected owner [v5]
In-Reply-To: <qXonY64Tq0lRSrpqGH86L7qGC1lpTmNZtQk54HFbHG4=.08c6864e-b84b-48ff-90e3-4d0768b42c45@github.com>
References: <qXonY64Tq0lRSrpqGH86L7qGC1lpTmNZtQk54HFbHG4=.08c6864e-b84b-48ff-90e3-4d0768b42c45@github.com>
Message-ID: <H4BoA3WVp5L-EObqYkcC3gEqeEHlN_Zkfzolw0vHBJU=.b15b4631-d1ac-4156-9ed1-40e812d82c11@github.com>

> This is the test issue. The `WaitingPT3` thread posted the `MonitorWait` event but has not released the `lockCheck` monitor yet. It has been fixed to wait for each `WaitingTask` thread to really reach the `WAITING` state. The same approach is used for `EnteringTask` threads. It has been fixed to wait for each `EnteringTask` thread to reach the `BLOCKED_ON_MONITOR` state.
> 
> Testing:
>  - Reran the test `serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java` locally
>  - TBD: submit the mach5 tiers 1-6 as well

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

  review: rename ensureWaitsToBeNotified to ensureWaitingToBeNotified

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18778/files
  - new: https://git.openjdk.org/jdk/pull/18778/files/0b2500d5..24322947

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

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

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

From sspitsyn at openjdk.org  Wed Apr 24 00:19:27 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 24 Apr 2024 00:19:27 GMT
Subject: RFR: 8330303: Crash: assert(_target_jt == nullptr ||
 _target_jt->vthread() == target_h()) failed
In-Reply-To: <s2XOP447huiEO4ph2kU-LkemkBxloUBcbcdtYOOnCpo=.98c07b6f-9e71-4e66-ac3d-7eab1c805dfc@github.com>
References: <s2XOP447huiEO4ph2kU-LkemkBxloUBcbcdtYOOnCpo=.98c07b6f-9e71-4e66-ac3d-7eab1c805dfc@github.com>
Message-ID: <NUqeg-wH7BDDnnYAQn8BUHVQCvve4yyoAFHujPQw93c=.253c78d4-99ab-4aaa-8f41-de4a302d54d9@github.com>

On Wed, 17 Apr 2024 00:29:52 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This is a simple fix of three similar asserts.
> The `_target_jt->jvmti_vthread()` has to be used instead of `_target_jt->vthread()`. 
> The `_target_jt->vthread()` can be outdated in some specific contexts as shown in the `hs_err` stack trace.
> 
> I've seen similar issue and already fixed it in this fragment of code:
> 
> class GetCurrentLocationClosure : public JvmtiUnitedHandshakeClosure {
>   . . .
>   void do_vthread(Handle target_h) {
>     assert(_target_jt == nullptr || !_target_jt->is_exiting(), "sanity check");
>     // use jvmti_vthread() as vthread() can be outdated
>     assert(_target_jt == nullptr || _target_jt->jvmti_vthread() == target_h(), "sanity check");
>     . . .
> 
> The issue above was fixed by replacing `_target_jt->vthread()` with `_target_jt->jvmti_vthread()`.
> 
> There are three places which need to be fixed the same way:
>  - `GetSingleStackTraceClosure::do_vthread(Handle target_h)`
>  - `SetForceEarlyReturn::do_vthread(Handle target_h)`
>  - `UpdateForPopTopFrameClosure::do_vthread(Handle target_h)`
> 
> Testing:
>  - Run mach5 tiers 1-6

Thank you for review, Leonid!

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

PR Comment: https://git.openjdk.org/jdk/pull/18806#issuecomment-2073695339

From sspitsyn at openjdk.org  Wed Apr 24 00:29:39 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 24 Apr 2024 00:29:39 GMT
Subject: RFR: 8330303: Crash: assert(_target_jt == nullptr ||
 _target_jt->vthread() == target_h()) failed [v2]
In-Reply-To: <s2XOP447huiEO4ph2kU-LkemkBxloUBcbcdtYOOnCpo=.98c07b6f-9e71-4e66-ac3d-7eab1c805dfc@github.com>
References: <s2XOP447huiEO4ph2kU-LkemkBxloUBcbcdtYOOnCpo=.98c07b6f-9e71-4e66-ac3d-7eab1c805dfc@github.com>
Message-ID: <_ThMMAId660RlwembjyrJLnCTa0WPoGt2M7gaFFnGMA=.d6e02633-f859-470a-8748-be77c055750e@github.com>

> This is a simple fix of three similar asserts.
> The `_target_jt->jvmti_vthread()` has to be used instead of `_target_jt->vthread()`. 
> The `_target_jt->vthread()` can be outdated in some specific contexts as shown in the `hs_err` stack trace.
> 
> I've seen similar issue and already fixed it in this fragment of code:
> 
> class GetCurrentLocationClosure : public JvmtiUnitedHandshakeClosure {
>   . . .
>   void do_vthread(Handle target_h) {
>     assert(_target_jt == nullptr || !_target_jt->is_exiting(), "sanity check");
>     // use jvmti_vthread() as vthread() can be outdated
>     assert(_target_jt == nullptr || _target_jt->jvmti_vthread() == target_h(), "sanity check");
>     . . .
> 
> The issue above was fixed by replacing `_target_jt->vthread()` with `_target_jt->jvmti_vthread()`.
> 
> There are three places which need to be fixed the same way:
>  - `GetSingleStackTraceClosure::do_vthread(Handle target_h)`
>  - `SetForceEarlyReturn::do_vthread(Handle target_h)`
>  - `UpdateForPopTopFrameClosure::do_vthread(Handle target_h)`
> 
> Testing:
>  - Run mach5 tiers 1-6

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

  review: updated same clarifying comment in several spots

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18806/files
  - new: https://git.openjdk.org/jdk/pull/18806/files/55a8ed10..6ac3b54f

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

  Stats: 8 lines in 3 files changed: 4 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/18806.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18806/head:pull/18806

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

From sspitsyn at openjdk.org  Wed Apr 24 02:49:56 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 24 Apr 2024 02:49:56 GMT
Subject: RFR: 8330303: Crash: assert(_target_jt == nullptr ||
 _target_jt->vthread() == target_h()) failed [v3]
In-Reply-To: <s2XOP447huiEO4ph2kU-LkemkBxloUBcbcdtYOOnCpo=.98c07b6f-9e71-4e66-ac3d-7eab1c805dfc@github.com>
References: <s2XOP447huiEO4ph2kU-LkemkBxloUBcbcdtYOOnCpo=.98c07b6f-9e71-4e66-ac3d-7eab1c805dfc@github.com>
Message-ID: <0hQI5q8pztB_S9cIYZf70NkBgV_eFBSrFT5jEdMvtFo=.06cbbdd8-c84f-4d60-819b-a8364af32bb6@github.com>

> This is a simple fix of three similar asserts.
> The `_target_jt->jvmti_vthread()` has to be used instead of `_target_jt->vthread()`. 
> The `_target_jt->vthread()` can be outdated in some specific contexts as shown in the `hs_err` stack trace.
> 
> I've seen similar issue and already fixed it in this fragment of code:
> 
> class GetCurrentLocationClosure : public JvmtiUnitedHandshakeClosure {
>   . . .
>   void do_vthread(Handle target_h) {
>     assert(_target_jt == nullptr || !_target_jt->is_exiting(), "sanity check");
>     // use jvmti_vthread() as vthread() can be outdated
>     assert(_target_jt == nullptr || _target_jt->jvmti_vthread() == target_h(), "sanity check");
>     . . .
> 
> The issue above was fixed by replacing `_target_jt->vthread()` with `_target_jt->jvmti_vthread()`.
> 
> There are three places which need to be fixed the same way:
>  - `GetSingleStackTraceClosure::do_vthread(Handle target_h)`
>  - `SetForceEarlyReturn::do_vthread(Handle target_h)`
>  - `UpdateForPopTopFrameClosure::do_vthread(Handle target_h)`
> 
> Testing:
>  - Run mach5 tiers 1-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 four additional commits since the last revision:

 - ?Merge?
 - review: updated same clarifying comment in several spots
 - add comments explaining that the vthread() can return outdated oop
 - 8330303: Crash: assert(_target_jt == nullptr || _target_jt->vthread() == target_h()) failed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18806/files
  - new: https://git.openjdk.org/jdk/pull/18806/files/6ac3b54f..c5ad80d0

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

  Stats: 52905 lines in 671 files changed: 26069 ins; 23980 del; 2856 mod
  Patch: https://git.openjdk.org/jdk/pull/18806.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18806/head:pull/18806

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

From cjplummer at openjdk.org  Wed Apr 24 05:45:32 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 24 Apr 2024 05:45:32 GMT
Subject: RFR: 8328741:
 serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java failed with
 unexpected owner [v5]
In-Reply-To: <H4BoA3WVp5L-EObqYkcC3gEqeEHlN_Zkfzolw0vHBJU=.b15b4631-d1ac-4156-9ed1-40e812d82c11@github.com>
References: <qXonY64Tq0lRSrpqGH86L7qGC1lpTmNZtQk54HFbHG4=.08c6864e-b84b-48ff-90e3-4d0768b42c45@github.com>
 <H4BoA3WVp5L-EObqYkcC3gEqeEHlN_Zkfzolw0vHBJU=.b15b4631-d1ac-4156-9ed1-40e812d82c11@github.com>
Message-ID: <ZtSXhfHdE842zBAyzz-e4mAEJOOfjrhyvB04WQdga5k=.66e1d035-a008-45f2-8322-b4b45be967b4@github.com>

On Wed, 24 Apr 2024 00:01:45 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is the test issue. The `WaitingPT3` thread posted the `MonitorWait` event but has not released the `lockCheck` monitor yet. It has been fixed to wait for each `WaitingTask` thread to really reach the `WAITING` state. The same approach is used for `EnteringTask` threads. It has been fixed to wait for each `EnteringTask` thread to reach the `BLOCKED_ON_MONITOR` state.
>> 
>> Testing:
>>  - Reran the test `serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java` locally
>>  - TBD: submit the mach5 tiers 1-6 as well
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: rename ensureWaitsToBeNotified to ensureWaitingToBeNotified

Looks good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18778#pullrequestreview-2018891935

From cjplummer at openjdk.org  Wed Apr 24 05:48:31 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 24 Apr 2024 05:48:31 GMT
Subject: RFR: 8330303: Crash: assert(_target_jt == nullptr ||
 _target_jt->vthread() == target_h()) failed [v3]
In-Reply-To: <0hQI5q8pztB_S9cIYZf70NkBgV_eFBSrFT5jEdMvtFo=.06cbbdd8-c84f-4d60-819b-a8364af32bb6@github.com>
References: <s2XOP447huiEO4ph2kU-LkemkBxloUBcbcdtYOOnCpo=.98c07b6f-9e71-4e66-ac3d-7eab1c805dfc@github.com>
 <0hQI5q8pztB_S9cIYZf70NkBgV_eFBSrFT5jEdMvtFo=.06cbbdd8-c84f-4d60-819b-a8364af32bb6@github.com>
Message-ID: <KJqmeV1p6YISkEmxuGyzsKVWZ0UREOLshsXYsRSmVck=.54f33cf3-20ad-4df6-ae91-d73451cad736@github.com>

On Wed, 24 Apr 2024 02:49:56 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is a simple fix of three similar asserts.
>> The `_target_jt->jvmti_vthread()` has to be used instead of `_target_jt->vthread()`. 
>> The `_target_jt->vthread()` can be outdated in some specific contexts as shown in the `hs_err` stack trace.
>> 
>> I've seen similar issue and already fixed it in this fragment of code:
>> 
>> class GetCurrentLocationClosure : public JvmtiUnitedHandshakeClosure {
>>   . . .
>>   void do_vthread(Handle target_h) {
>>     assert(_target_jt == nullptr || !_target_jt->is_exiting(), "sanity check");
>>     // use jvmti_vthread() as vthread() can be outdated
>>     assert(_target_jt == nullptr || _target_jt->jvmti_vthread() == target_h(), "sanity check");
>>     . . .
>> 
>> The issue above was fixed by replacing `_target_jt->vthread()` with `_target_jt->jvmti_vthread()`.
>> 
>> There are three places which need to be fixed the same way:
>>  - `GetSingleStackTraceClosure::do_vthread(Handle target_h)`
>>  - `SetForceEarlyReturn::do_vthread(Handle target_h)`
>>  - `UpdateForPopTopFrameClosure::do_vthread(Handle target_h)`
>> 
>> Testing:
>>  - Run mach5 tiers 1-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 four additional commits since the last revision:
> 
>  - ?Merge?
>  - review: updated same clarifying comment in several spots
>  - add comments explaining that the vthread() can return outdated oop
>  - 8330303: Crash: assert(_target_jt == nullptr || _target_jt->vthread() == target_h()) failed

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

> 2077: void
> 2078: GetSingleStackTraceClosure::do_vthread(Handle target_h) {
> 2079:   // Use jvmti_vthread() instead of vthread() as target could have temporary changed

Suggestion:

  // Use jvmti_vthread() instead of vthread() as target could have temporarily changed

src/hotspot/share/prims/jvmtiEnvBase.hpp line 509:

> 507:   void do_vthread(Handle target_h) {
> 508:     assert(_target_jt != nullptr, "sanity check");
> 509:     // Use jvmti_vthread() instead of vthread() as target could have temporary changed

Suggestion:

    // Use jvmti_vthread() instead of vthread() as target could have temporarily changed

src/hotspot/share/prims/jvmtiEnvBase.hpp line 531:

> 529:   void do_vthread(Handle target_h) {
> 530:     assert(_target_jt != nullptr, "sanity check");
> 531:     // Use jvmti_vthread() instead of vthread() as target could have temporary changed

Suggestion:

    // Use jvmti_vthread() instead of vthread() as target could have temporarily changed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18806#discussion_r1577299642
PR Review Comment: https://git.openjdk.org/jdk/pull/18806#discussion_r1577299918
PR Review Comment: https://git.openjdk.org/jdk/pull/18806#discussion_r1577300305

From smonteith at openjdk.org  Wed Apr 24 07:20:29 2024
From: smonteith at openjdk.org (Stuart Monteith)
Date: Wed, 24 Apr 2024 07:20:29 GMT
Subject: RFR: 8330171: Lazy W^X switch implementation
In-Reply-To: <Ypy3borKtPa_pBCqZKQnF6ULfIuw93R1YDBQhaDUl4o=.aa7eef47-d3d2-48ef-a448-75d400ffbb28@github.com>
References: <9eymaXovxUNFdkAkzojFQP5trwl_yyY0jE2GzcMEjR4=.02ee2ef9-c476-4c7c-9e4a-e021425c38bc@github.com>
 <DGjOTJjWNyRdiUDzupUmGBzS6N7anW3ECzYAtjRUZOQ=.310e6e2a-a387-407b-a293-a14381c04980@github.com>
 <Ypy3borKtPa_pBCqZKQnF6ULfIuw93R1YDBQhaDUl4o=.aa7eef47-d3d2-48ef-a448-75d400ffbb28@github.com>
Message-ID: <_o-DnTvlCXTP8lho_6sJOEwgOBgn5lzYEJno-uCVRqQ=.ffb3f85e-89dd-44b4-b650-6a4ba79ba20d@github.com>

On Tue, 23 Apr 2024 15:11:10 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> What about granting `WXWrite` only if the current thread is in `_thread_in_vm`?
>> That would be more restrictive and roughly equivalent how it currently works. Likely there are some places then that should be granted `WXWrite` eagerly because they need `WXWrite` without `_thread_in_vm`. E.g. the JIT compiler threads should have `WXWrite` and never `WXExec` (I assume) which should be checked in the signal handler.
>
>> The patch doesn't protect against native agents, as this is obviously impossible. The current code doesn't do that either. For the bytecode, it doesn't prevent the attacker from abusing unsafe api to modify code cache. However unsafe functions are already considered "safe" and we proactively enable WXWrite as well as move thread to `_thread_in_vm` state (@reinrich). JITed code can't write to the cache either with or without the patch.
>> 
>> I totally get the sense of loss of security. But is this really the case?
> 
> I think it is. W^X is intended (amongst other things) to protect against the use of gadgets, from buffer overflow exploits in non-java code to ROP programming. At present, in order to generate code and execute it, you first have to be able to make the JIT code writable, then write the code, then make it executable. then jump to the code. And the exploit writer might have to do some or all of this by finding gadgets. If we were to merge this patch then all the attacker would have to do is write code to memory and find a way to jump to it, and the automatic switch-on-segfault in this patch would do the all the work the attacker needs.
> 
> It makes far more sense to tag those places that actually need to change W^X access, and only switch there.
> 
> You could argue that any switching of W^X on a write to code space, then switching it back on jumping (or returning) to Java code, even what we already do, is effectively the same thing. Kinda, but it's not on just any attempt to write to code space or any attempt to jump into code, it's at the places we choose, and we can be careful to limit those places.
> 
> But surely the JDK is not the most vulnerable part of the stack anyway? I'd agree with that, of course, but I don't think that's sufficient reason to decide to bypass an OS security mechanism.
> 
> We are trying to reduce the size of the attack surface.

To add a little to @theRealAph 's point, we should avoid painting ourselves into a corner. I don't know how the platform is going to evolve, but I'd be nervous about fighting against the intentions of the protections.

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

PR Comment: https://git.openjdk.org/jdk/pull/18762#issuecomment-2074244082

From ayang at openjdk.org  Wed Apr 24 07:29:29 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 24 Apr 2024 07:29:29 GMT
Subject: RFR: 8330155: Serial: Remove TenuredSpace [v3]
In-Reply-To: <eCWiw2FKdSBPI5TBJbZwTgg2qSlR3UnnYwo-BHgrSvg=.4a3cd2f5-f3a7-485e-8954-f69b14da602c@github.com>
References: <akIgBAk_kI6GQ8orQgn1h1KDPcs1H2AZlq9EHgVLYWI=.e6363e84-1349-464a-98c9-232ba97c2758@github.com>
 <eCWiw2FKdSBPI5TBJbZwTgg2qSlR3UnnYwo-BHgrSvg=.4a3cd2f5-f3a7-485e-8954-f69b14da602c@github.com>
Message-ID: <ctIIBxh4YJAGPlbMjUoRFub0kab_rSi4r0e_FM7ZlgI=.1099938c-d8d5-47ef-a847-5ecafe93ba9c@github.com>

On Tue, 23 Apr 2024 17:22:41 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch removes the class `TenuredSpace` and adjusts its usages. After removing `TenuredSpace`, the file `space.inline.hpp` is empty, so I remove this file and change the included header file to `space.hpp`.
>> 
>> The test `make test-tier1_gc` passed locally. Thanks for taking the time to review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix included header file error after merging master.

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18894#pullrequestreview-2019079434

From sspitsyn at openjdk.org  Wed Apr 24 09:04:32 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 24 Apr 2024 09:04:32 GMT
Subject: RFR: 8328741:
 serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java failed with
 unexpected owner [v5]
In-Reply-To: <H4BoA3WVp5L-EObqYkcC3gEqeEHlN_Zkfzolw0vHBJU=.b15b4631-d1ac-4156-9ed1-40e812d82c11@github.com>
References: <qXonY64Tq0lRSrpqGH86L7qGC1lpTmNZtQk54HFbHG4=.08c6864e-b84b-48ff-90e3-4d0768b42c45@github.com>
 <H4BoA3WVp5L-EObqYkcC3gEqeEHlN_Zkfzolw0vHBJU=.b15b4631-d1ac-4156-9ed1-40e812d82c11@github.com>
Message-ID: <TG2ytRbKJE3BblNFKiqO31lCDebpvQP_eLIQVGUPS08=.a4c58d94-0258-4b89-92d2-1588ceae1d77@github.com>

On Wed, 24 Apr 2024 00:01:45 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is the test issue. The `WaitingPT3` thread posted the `MonitorWait` event but has not released the `lockCheck` monitor yet. It has been fixed to wait for each `WaitingTask` thread to really reach the `WAITING` state. The same approach is used for `EnteringTask` threads. It has been fixed to wait for each `EnteringTask` thread to reach the `BLOCKED_ON_MONITOR` state.
>> 
>> Testing:
>>  - Reran the test `serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java` locally
>>  - TBD: submit the mach5 tiers 1-6 as well
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: rename ensureWaitsToBeNotified to ensureWaitingToBeNotified

Thank you for review, Leonid and Chris!

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

PR Comment: https://git.openjdk.org/jdk/pull/18778#issuecomment-2074450724

From sspitsyn at openjdk.org  Wed Apr 24 09:04:33 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 24 Apr 2024 09:04:33 GMT
Subject: Integrated: 8328741:
 serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java failed with
 unexpected owner
In-Reply-To: <qXonY64Tq0lRSrpqGH86L7qGC1lpTmNZtQk54HFbHG4=.08c6864e-b84b-48ff-90e3-4d0768b42c45@github.com>
References: <qXonY64Tq0lRSrpqGH86L7qGC1lpTmNZtQk54HFbHG4=.08c6864e-b84b-48ff-90e3-4d0768b42c45@github.com>
Message-ID: <X162RFpfH1U9_5Z7WJ2fVv1CQlQuYqOj03TsutSwPvg=.c326f4f2-1396-42ec-b6b5-ced2d599af65@github.com>

On Mon, 15 Apr 2024 06:47:24 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This is the test issue. The `WaitingPT3` thread posted the `MonitorWait` event but has not released the `lockCheck` monitor yet. It has been fixed to wait for each `WaitingTask` thread to really reach the `WAITING` state. The same approach is used for `EnteringTask` threads. It has been fixed to wait for each `EnteringTask` thread to reach the `BLOCKED_ON_MONITOR` state.
> 
> Testing:
>  - Reran the test `serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java` locally
>  - TBD: submit the mach5 tiers 1-6 as well

This pull request has now been integrated.

Changeset: 174d6265
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/174d62652c69e811cf44ab64db575b13a848a728
Stats:     114 lines in 4 files changed: 20 ins; 80 del; 14 mod

8328741: serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java failed with unexpected owner

Reviewed-by: lmesnik, cjplummer

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

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

From ihse at openjdk.org  Wed Apr 24 09:17:28 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 24 Apr 2024 09:17:28 GMT
Subject: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for
 hsdis
In-Reply-To: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
References: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
Message-ID: <usSjNoHaMLDK2yN1CVz7X91uSIbpQslnD0hBtTFtnsw=.e7b4dede-07bf-41af-bef1-02672ef4758d@github.com>

On Tue, 23 Apr 2024 13:56:32 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> WIP
> 
> This changeset contains hsdis for Windows/gcc Port. It supports both the binutils and capstone backends, though the LLVM backend is left out due to compatibility issues encountered during the build. Currently, which gcc distributions are supported is still to be clarified, as several, ranging from Cygwin, to MinGW64, to the gcc subsystems from MSYS2. For this reason, the build system hack in place at the moment to compile the binutils backend on Windows is still left in place, for now.

Please mark the PR as draft it is not intended for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/18915#issuecomment-2074481887

From sspitsyn at openjdk.org  Wed Apr 24 09:59:54 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 24 Apr 2024 09:59:54 GMT
Subject: RFR: 8330303: Crash: assert(_target_jt == nullptr ||
 _target_jt->vthread() == target_h()) failed [v4]
In-Reply-To: <s2XOP447huiEO4ph2kU-LkemkBxloUBcbcdtYOOnCpo=.98c07b6f-9e71-4e66-ac3d-7eab1c805dfc@github.com>
References: <s2XOP447huiEO4ph2kU-LkemkBxloUBcbcdtYOOnCpo=.98c07b6f-9e71-4e66-ac3d-7eab1c805dfc@github.com>
Message-ID: <V0MkdFcu6l6L4YqnB6CnQoq-6vo38XtTuK4PK6Dpf2Q=.54362dff-5235-4674-97ac-abf26dd75f42@github.com>

> This is a simple fix of three similar asserts.
> The `_target_jt->jvmti_vthread()` has to be used instead of `_target_jt->vthread()`. 
> The `_target_jt->vthread()` can be outdated in some specific contexts as shown in the `hs_err` stack trace.
> 
> I've seen similar issue and already fixed it in this fragment of code:
> 
> class GetCurrentLocationClosure : public JvmtiUnitedHandshakeClosure {
>   . . .
>   void do_vthread(Handle target_h) {
>     assert(_target_jt == nullptr || !_target_jt->is_exiting(), "sanity check");
>     // use jvmti_vthread() as vthread() can be outdated
>     assert(_target_jt == nullptr || _target_jt->jvmti_vthread() == target_h(), "sanity check");
>     . . .
> 
> The issue above was fixed by replacing `_target_jt->vthread()` with `_target_jt->jvmti_vthread()`.
> 
> There are three places which need to be fixed the same way:
>  - `GetSingleStackTraceClosure::do_vthread(Handle target_h)`
>  - `SetForceEarlyReturn::do_vthread(Handle target_h)`
>  - `UpdateForPopTopFrameClosure::do_vthread(Handle target_h)`
> 
> Testing:
>  - Run mach5 tiers 1-6

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

  review: fixed typo in same comment in several spots

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18806/files
  - new: https://git.openjdk.org/jdk/pull/18806/files/c5ad80d0..643c3046

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

  Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/18806.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18806/head:pull/18806

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

From sspitsyn at openjdk.org  Wed Apr 24 09:59:56 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 24 Apr 2024 09:59:56 GMT
Subject: RFR: 8330303: Crash: assert(_target_jt == nullptr ||
 _target_jt->vthread() == target_h()) failed [v3]
In-Reply-To: <KJqmeV1p6YISkEmxuGyzsKVWZ0UREOLshsXYsRSmVck=.54f33cf3-20ad-4df6-ae91-d73451cad736@github.com>
References: <s2XOP447huiEO4ph2kU-LkemkBxloUBcbcdtYOOnCpo=.98c07b6f-9e71-4e66-ac3d-7eab1c805dfc@github.com>
 <0hQI5q8pztB_S9cIYZf70NkBgV_eFBSrFT5jEdMvtFo=.06cbbdd8-c84f-4d60-819b-a8364af32bb6@github.com>
 <KJqmeV1p6YISkEmxuGyzsKVWZ0UREOLshsXYsRSmVck=.54f33cf3-20ad-4df6-ae91-d73451cad736@github.com>
Message-ID: <DpHe0Y4cdt-OsPf6onK0FYBSks1ZJ3nsAAxGA9MHJS0=.489a0716-8f11-4a2c-b9d3-3d85c2572604@github.com>

On Wed, 24 Apr 2024 05:44:42 GMT, Chris Plummer <cjplummer 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 four additional commits since the last revision:
>> 
>>  - ?Merge?
>>  - review: updated same clarifying comment in several spots
>>  - add comments explaining that the vthread() can return outdated oop
>>  - 8330303: Crash: assert(_target_jt == nullptr || _target_jt->vthread() == target_h()) failed
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 2079:
> 
>> 2077: void
>> 2078: GetSingleStackTraceClosure::do_vthread(Handle target_h) {
>> 2079:   // Use jvmti_vthread() instead of vthread() as target could have temporary changed
> 
> Suggestion:
> 
>   // Use jvmti_vthread() instead of vthread() as target could have temporarily changed

Good catch, fixed now.

> src/hotspot/share/prims/jvmtiEnvBase.hpp line 509:
> 
>> 507:   void do_vthread(Handle target_h) {
>> 508:     assert(_target_jt != nullptr, "sanity check");
>> 509:     // Use jvmti_vthread() instead of vthread() as target could have temporary changed
> 
> Suggestion:
> 
>     // Use jvmti_vthread() instead of vthread() as target could have temporarily changed

Good catch, thanks. Fixed now.

> src/hotspot/share/prims/jvmtiEnvBase.hpp line 531:
> 
>> 529:   void do_vthread(Handle target_h) {
>> 530:     assert(_target_jt != nullptr, "sanity check");
>> 531:     // Use jvmti_vthread() instead of vthread() as target could have temporary changed
> 
> Suggestion:
> 
>     // Use jvmti_vthread() instead of vthread() as target could have temporarily changed

Good catch, thanks. Fixed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18806#discussion_r1577621820
PR Review Comment: https://git.openjdk.org/jdk/pull/18806#discussion_r1577623055
PR Review Comment: https://git.openjdk.org/jdk/pull/18806#discussion_r1577622556

From brice.dutheil at gmail.com  Wed Apr 24 11:13:50 2024
From: brice.dutheil at gmail.com (Brice Dutheil)
Date: Wed, 24 Apr 2024 13:13:50 +0200
Subject: RFO: a tool to analyze HotSpot fatal error logs
In-Reply-To: <76ed1a5d-ec36-4e2c-a31a-af4c80b592a1@oracle.com>
References: <CAG0Tb0iiDxhLuG1Bkg=8xusAUyoX9ZyKt64rnP22Sau9LNvWJw@mail.gmail.com>
 <76ed1a5d-ec36-4e2c-a31a-af4c80b592a1@oracle.com>
Message-ID: <CALTMA7th3fmsZVHgJvSmLH78fHqyPUZLm5BftcGnmH-mWutp=A@mail.gmail.com>

I would find this tool particularly useful. I came across various
`hs_err_pid` files, while one can read them this can speed analyzing up
significantly.

Even for simple cases, like a bug in the FFM API usage (it's still possible
to dereference a bad address).

Looking forward to this plugin !

Thanks for proposing the idea.
-- Brice


On Fri, Apr 12, 2024 at 5:35?PM Laurence Cable <larry.cable at oracle.com>
wrote:

> Hi Maxim, a great idea, the JDK serviceability team here at Oracle would
> like to assist you in any way we can.
>
> I think also we should (in the future) consider the format of the error
> file and associated jcmd and perhaps render the content
> in a format that is better suited to programmatic parsing even a
> jq-esque formatter that took the human-readable format and
> re-formatted would be useful (IMO)
>
> Rgds
>
> - Larry Cable
>
>
> On 4/11/24 7:05 AM, Maxim Kartashev wrote:
> > Hello,
> >
> > I am writing to inquire about the potential interest of the people
> > involved in inspecting HotSpot crashes in a tool aimed at facilitating
> > that inspection.
> >
> > We at JetBrains have developed an internal plugin that helps both with
> > filtering through dozens of reports quickly in order to find a pattern
> > and for diving deep into a particular crash. In addition to the
> > "standard" features such as syntax highlighting, folding, and
> > structural navigation, it will
> > * highlight potential problems such as overloaded CPU, low physical
> > memory, the presence of OOME in the recent exceptions, LD_LIBRARY_PATH
> > being set, etc,
> > * generate an "executive summary" for a high-level overview, for
> > example, by front-line support,
> > * pop up a tooltip for any recognized address describing its origin
> > (for example, if it belongs to some thread's stack, the Java heap, a
> > register, or a memory-mapped region),
> > * provide the ability to highlight all addresses "near" the selected
> > address, including registers, threads, and memory-mapped regions.
> >
> > If there is sufficient interest in creating a public and/or
> > open-source variant of this internal plugin, I will pitch the idea to
> > my employer. It shouldn't be too much work to create a public version.
> >
> > Kind regards,
> > Maxim.
> >
> > References:
> > * https://docs.oracle.com/javase/10/troubleshoot/fatal-error-log.htm
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20240424/3585f220/attachment.htm>

From gli at openjdk.org  Wed Apr 24 11:44:35 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Wed, 24 Apr 2024 11:44:35 GMT
Subject: RFR: 8330155: Serial: Remove TenuredSpace [v3]
In-Reply-To: <eCWiw2FKdSBPI5TBJbZwTgg2qSlR3UnnYwo-BHgrSvg=.4a3cd2f5-f3a7-485e-8954-f69b14da602c@github.com>
References: <akIgBAk_kI6GQ8orQgn1h1KDPcs1H2AZlq9EHgVLYWI=.e6363e84-1349-464a-98c9-232ba97c2758@github.com>
 <eCWiw2FKdSBPI5TBJbZwTgg2qSlR3UnnYwo-BHgrSvg=.4a3cd2f5-f3a7-485e-8954-f69b14da602c@github.com>
Message-ID: <PyOUrqqqsUpvf3MCv-Ysfv99rXWRC37u9xt3BrGwGHI=.1f3242db-40c7-499b-8513-6f8ba8bd63c0@github.com>

On Tue, 23 Apr 2024 17:22:41 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch removes the class `TenuredSpace` and adjusts its usages. After removing `TenuredSpace`, the file `space.inline.hpp` is empty, so I remove this file and change the included header file to `space.hpp`.
>> 
>> The test `make test-tier1_gc` passed locally. Thanks for taking the time to review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix included header file error after merging master.

Thanks for the reviews. Integrating.

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

PR Comment: https://git.openjdk.org/jdk/pull/18894#issuecomment-2074744514

From gli at openjdk.org  Wed Apr 24 11:44:36 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Wed, 24 Apr 2024 11:44:36 GMT
Subject: Integrated: 8330155: Serial: Remove TenuredSpace
In-Reply-To: <akIgBAk_kI6GQ8orQgn1h1KDPcs1H2AZlq9EHgVLYWI=.e6363e84-1349-464a-98c9-232ba97c2758@github.com>
References: <akIgBAk_kI6GQ8orQgn1h1KDPcs1H2AZlq9EHgVLYWI=.e6363e84-1349-464a-98c9-232ba97c2758@github.com>
Message-ID: <2YnKivyjPw42Mzul57zi3XRl8gNWh9SMZFwiLfWEfM8=.c6759245-2395-4794-9313-f65f2b4f6d3d@github.com>

On Mon, 22 Apr 2024 16:24:06 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch removes the class `TenuredSpace` and adjusts its usages. After removing `TenuredSpace`, the file `space.inline.hpp` is empty, so I remove this file and change the included header file to `space.hpp`.
> 
> The test `make test-tier1_gc` passed locally. Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

This pull request has now been integrated.

Changeset: 2bb5cf5f
Author:    Guoxiong Li <gli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2bb5cf5f33337b2cc40aca3bdd36400dc4af5723
Stats:     162 lines in 21 files changed: 11 ins; 127 del; 24 mod

8330155: Serial: Remove TenuredSpace

Reviewed-by: ayang, cjplummer, tschatzl

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

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

From sspitsyn at openjdk.org  Wed Apr 24 11:46:34 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 24 Apr 2024 11:46:34 GMT
Subject: Integrated: 8330303: Crash: assert(_target_jt == nullptr ||
 _target_jt->vthread() == target_h()) failed
In-Reply-To: <s2XOP447huiEO4ph2kU-LkemkBxloUBcbcdtYOOnCpo=.98c07b6f-9e71-4e66-ac3d-7eab1c805dfc@github.com>
References: <s2XOP447huiEO4ph2kU-LkemkBxloUBcbcdtYOOnCpo=.98c07b6f-9e71-4e66-ac3d-7eab1c805dfc@github.com>
Message-ID: <JyOdA_L_OAkfNaoEOvTSJ82XogF2n6JwNHbbzm7XHZE=.2249f6eb-69d1-49db-9c3e-32b7265ff455@github.com>

On Wed, 17 Apr 2024 00:29:52 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This is a simple fix of three similar asserts.
> The `_target_jt->jvmti_vthread()` has to be used instead of `_target_jt->vthread()`. 
> The `_target_jt->vthread()` can be outdated in some specific contexts as shown in the `hs_err` stack trace.
> 
> I've seen similar issue and already fixed it in this fragment of code:
> 
> class GetCurrentLocationClosure : public JvmtiUnitedHandshakeClosure {
>   . . .
>   void do_vthread(Handle target_h) {
>     assert(_target_jt == nullptr || !_target_jt->is_exiting(), "sanity check");
>     // use jvmti_vthread() as vthread() can be outdated
>     assert(_target_jt == nullptr || _target_jt->jvmti_vthread() == target_h(), "sanity check");
>     . . .
> 
> The issue above was fixed by replacing `_target_jt->vthread()` with `_target_jt->jvmti_vthread()`.
> 
> There are three places which need to be fixed the same way:
>  - `GetSingleStackTraceClosure::do_vthread(Handle target_h)`
>  - `SetForceEarlyReturn::do_vthread(Handle target_h)`
>  - `UpdateForPopTopFrameClosure::do_vthread(Handle target_h)`
> 
> Testing:
>  - Run mach5 tiers 1-6

This pull request has now been integrated.

Changeset: 15190816
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/15190816f704f2e8681bc3e2d74832828a574106
Stats:     11 lines in 3 files changed: 7 ins; 0 del; 4 mod

8330303: Crash: assert(_target_jt == nullptr || _target_jt->vthread() == target_h()) failed

Reviewed-by: pchilanomate, cjplummer, lmesnik

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

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

From sspitsyn at openjdk.org  Wed Apr 24 16:11:50 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 24 Apr 2024 16:11:50 GMT
Subject: RFR: 8330969: scalability issue with loaded JVMTI agent
Message-ID: <FvcDTtfEpTjQmcSjEPSmKjpUloHElpk6uUPc7VPjc2U=.01a08d3f-5906-4429-9472-61218603f613@github.com>

This is a fix of the following JVMTI scalability issue. A closed benchmark with millions of virtual threads shows 4X overhead when a JVMTI agent has been loaded. For instance, this is observable when an app is executed under control of the Oracle Studio `collect` utility.

The benchmark takes a little bit more than 3 sec without any JVMTI agent:

Total:               in 3045 ms


The benchmark takes more than ~3.2X of the above when executed with the `collect` utility:

Creating experiment database test.1.er (Process ID: 25262) ...
Picked up JAVA_TOOL_OPTIONS: -agentlib:collector
Total:               in 9864 ms


With the fix in place the overhead of a JVMTI agent is around 1.2X:

Creating experiment database test.1.er (Process ID: 26442) ...
Picked up JAVA_TOOL_OPTIONS: -agentlib:collector
Total:               in 3765 ms


The most of the overhead is taken by two functions:
 - `JvmtiVTMSTransitionDisabler::start_VTMS_transition()`
 - `JvmtiVTMSTransitionDisabler::finish_VTMS_transition()`
 
 Oracle Studio Performance Analyzer `err_print utility shows the following performance data for these functions:
 ```
% er_print -viewmode expert -metrics ie.%totalcpu -csingle JvmtiVTMSTransitionDisabler::start_VTMS_transition test.1.er

Attr. Total     Name
CPU
  sec.      %
=============== Callers
42.930  50.06   SharedRuntime::notify_jvmti_vthread_mount(oopDesc*, unsigned char, JavaThread*)
21.505  25.08   JvmtiVTMSTransitionDisabler::VTMS_vthread_end(_jobject*)
21.315  24.86   JvmtiVTMSTransitionDisabler::VTMS_vthread_unmount(_jobject*, bool)

=============== Stack Fragment
81.407  94.94   JvmtiVTMSTransitionDisabler::start_VTMS_transition(_jobject*, bool)

=============== Callees
 4.083   4.76   java_lang_Thread::set_is_in_VTMS_transition(oopDesc*, bool)
 0.140   0.16   __tls_get_addr
 0.120   0.14   JNIHandles::resolve_external_guard(_jobject*)



% er_print -viewmode expert -metrics ie.%totalcpu -csingle JvmtiVTMSTransitionDisabler::finish_VTMS_transition test.1.er

Attr. Total     Name
CPU
  sec.      %
=============== Callers
47.363  52.59   SharedRuntime::notify_jvmti_vthread_unmount(oopDesc*, unsigned char, JavaThread*)
21.355  23.71   JvmtiVTMSTransitionDisabler::VTMS_vthread_mount(_jobject*, bool)
21.345  23.70   JvmtiVTMSTransitionDisabler::VTMS_vthread_start(_jobject*)

=============== Stack Fragment
64.145  71.22   JvmtiVTMSTransitionDisabler::finish_VTMS_transition(_jobject*, bool)

=============== Callees
25.288  28.08   java_lang_Thread::set_is_in_VTMS_transition(oopDesc*, bool)
 0.240   0.27   __tls_get_addr
 0.200   0.22   JavaThread::set_is_in_VTMS_transition(bool)
 0.190   0.21   JNIHandles::resolve_external_guard(_jobject*)


The main source of this overhead (~90% of overhead) is atomic increment and decrement of the global counter `VTMS_transition_count`:
 - `Atomic::inc(&_VTMS_transition_count)`;
 - `Atomic::dec(&_VTMS_transition_count)`;
 

The fix is to replace this global counter with mark bits `_VTMS_transition_mark` distributed over all `JavaThread`'s.
If these lines are commented out or replaced with the distributed thread-local marks the main performance overhead is gone:

% er_print -viewmode expert -metrics ie.%totalcpu -csingle JvmtiVTMSTransitionDisabler::start_VTMS_transition test.2.er

Attr. Total    Name
CPU
 sec.      %
============== Callers
1.801  64.29   SharedRuntime::notify_jvmti_vthread_mount(oopDesc*, unsigned char, JavaThread*)
0.580  20.71   JvmtiVTMSTransitionDisabler::VTMS_vthread_unmount(_jobject*, bool)
0.420  15.00   JvmtiVTMSTransitionDisabler::VTMS_vthread_end(_jobject*)

============== Stack Fragment
0.630  22.50   JvmtiVTMSTransitionDisabler::start_VTMS_transition(_jobject*, bool)

============== Callees
1.931  68.93   java_lang_Thread::set_is_in_VTMS_transition(oopDesc*, bool)
0.220   7.86   __tls_get_addr
0.020   0.71   JNIHandles::resolve_external_guard(_jobject*)



% er_print -viewmode expert -metrics ie.%totalcpu -csingle JvmtiVTMSTransitionDisabler::finish_VTMS_transition test.2.er

Attr. Total    Name
CPU
 sec.      %
============== Callers
1.661  39.15   JvmtiVTMSTransitionDisabler::VTMS_vthread_mount(_jobject*, bool)
1.351  31.84   JvmtiVTMSTransitionDisabler::VTMS_vthread_start(_jobject*)
1.231  29.01   SharedRuntime::notify_jvmti_vthread_unmount(oopDesc*, unsigned char, JavaThread*)

============== Stack Fragment
0.500  11.79   JvmtiVTMSTransitionDisabler::finish_VTMS_transition(_jobject*, bool)

============== Callees
2.972  70.05   java_lang_Thread::set_is_in_VTMS_transition(oopDesc*, bool)
0.350   8.25   JavaThread::set_is_in_VTMS_transition(bool)
0.340   8.02   __tls_get_addr
0.080   1.89   JNIHandles::resolve_external_guard(_jobject*)


The rest of the overhead (~10% of total overhead) is taken by calls to the function `java_lang_Thread::set_is_in_VTMS_transition()`. The plan is to address this in a separate fix. But it is expected to be a little?bit more tricky.


Testing:
 - Tested with mach5 tiers 1-6

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

Commit messages:
 - 8330969: scalability issue with loaded JVMTI agent

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

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

From sspitsyn at openjdk.org  Wed Apr 24 18:26:29 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 24 Apr 2024 18:26:29 GMT
Subject: RFR: 8330969: scalability issue with loaded JVMTI agent
In-Reply-To: <FvcDTtfEpTjQmcSjEPSmKjpUloHElpk6uUPc7VPjc2U=.01a08d3f-5906-4429-9472-61218603f613@github.com>
References: <FvcDTtfEpTjQmcSjEPSmKjpUloHElpk6uUPc7VPjc2U=.01a08d3f-5906-4429-9472-61218603f613@github.com>
Message-ID: <8TqEB2KwelGJhLIvqRMWK2nVFlYAqKvoCffkvqacsHc=.88eb3ad9-5a39-4ecf-88c7-afe8e7a69943@github.com>

On Wed, 24 Apr 2024 16:04:30 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This is a fix of the following JVMTI scalability issue. A closed benchmark with millions of virtual threads shows 3X-4X overhead when a JVMTI agent has been loaded. For instance, this is observable when an app is executed under control of the Oracle Studio `collect` utility.
> For performance analysis, experiments and numbers, please, see the comment below this description.
> 
> The fix is to replace the global counter `_VTMS_transition_count` with the mark bit `_VTMS_transition_mark` in each `JavaThread`'.
> 
> Testing:
>  - Tested with mach5 tiers 1-6

The benchmark takes a little bit more than 3 sec without any JVMTI agent:

Total:               in 3045 ms


The benchmark takes more than ~3.2X of the above when executed with the `collect` utility:

Creating experiment database test.1.er (Process ID: 25262) ...
Picked up JAVA_TOOL_OPTIONS: -agentlib:collector
Total:               in 9864 ms


With the fix in place the overhead of a JVMTI agent is around 1.2X:

Creating experiment database test.1.er (Process ID: 26442) ...
Picked up JAVA_TOOL_OPTIONS: -agentlib:collector
Total:               in 3765 ms


The most of the overhead is taken by two functions:
 - `JvmtiVTMSTransitionDisabler::start_VTMS_transition()`
 - `JvmtiVTMSTransitionDisabler::finish_VTMS_transition()`
 
 Oracle Studio Performance Analyzer `err_print` utility shows the following performance data for these functions:
 ```
% er_print -viewmode expert -metrics ie.%totalcpu -csingle JvmtiVTMSTransitionDisabler::start_VTMS_transition test.1.er

Attr. Total     Name
CPU
  sec.      %
=============== Callers
42.930  50.06   SharedRuntime::notify_jvmti_vthread_mount(oopDesc*, unsigned char, JavaThread*)
21.505  25.08   JvmtiVTMSTransitionDisabler::VTMS_vthread_end(_jobject*)
21.315  24.86   JvmtiVTMSTransitionDisabler::VTMS_vthread_unmount(_jobject*, bool)

=============== Stack Fragment
81.407  94.94   JvmtiVTMSTransitionDisabler::start_VTMS_transition(_jobject*, bool)

=============== Callees
 4.083   4.76   java_lang_Thread::set_is_in_VTMS_transition(oopDesc*, bool)
 0.140   0.16   __tls_get_addr
 0.120   0.14   JNIHandles::resolve_external_guard(_jobject*)



% er_print -viewmode expert -metrics ie.%totalcpu -csingle JvmtiVTMSTransitionDisabler::finish_VTMS_transition test.1.er

Attr. Total     Name
CPU
  sec.      %
=============== Callers
47.363  52.59   SharedRuntime::notify_jvmti_vthread_unmount(oopDesc*, unsigned char, JavaThread*)
21.355  23.71   JvmtiVTMSTransitionDisabler::VTMS_vthread_mount(_jobject*, bool)
21.345  23.70   JvmtiVTMSTransitionDisabler::VTMS_vthread_start(_jobject*)

=============== Stack Fragment
64.145  71.22   JvmtiVTMSTransitionDisabler::finish_VTMS_transition(_jobject*, bool)

=============== Callees
25.288  28.08   java_lang_Thread::set_is_in_VTMS_transition(oopDesc*, bool)
 0.240   0.27   __tls_get_addr
 0.200   0.22   JavaThread::set_is_in_VTMS_transition(bool)
 0.190   0.21   JNIHandles::resolve_external_guard(_jobject*)


The main source of this overhead (~90% of overhead) is atomic increment and decrement of the global counter `VTMS_transition_count`:
 - `Atomic::inc(&_VTMS_transition_count)`;
 - `Atomic::dec(&_VTMS_transition_count)`;
 

The fix is to replace this global counter with mark bits `_VTMS_transition_mark` distributed over all `JavaThread`'s.
If these lines are commented out or replaced with the distributed thread-local marks the main performance overhead is gone:

% er_print -viewmode expert -metrics ie.%totalcpu -csingle JvmtiVTMSTransitionDisabler::start_VTMS_transition test.2.er

Attr. Total    Name
CPU
 sec.      %
============== Callers
1.801  64.29   SharedRuntime::notify_jvmti_vthread_mount(oopDesc*, unsigned char, JavaThread*)
0.580  20.71   JvmtiVTMSTransitionDisabler::VTMS_vthread_unmount(_jobject*, bool)
0.420  15.00   JvmtiVTMSTransitionDisabler::VTMS_vthread_end(_jobject*)

============== Stack Fragment
0.630  22.50   JvmtiVTMSTransitionDisabler::start_VTMS_transition(_jobject*, bool)

============== Callees
1.931  68.93   java_lang_Thread::set_is_in_VTMS_transition(oopDesc*, bool)
0.220   7.86   __tls_get_addr
0.020   0.71   JNIHandles::resolve_external_guard(_jobject*)



% er_print -viewmode expert -metrics ie.%totalcpu -csingle JvmtiVTMSTransitionDisabler::finish_VTMS_transition test.2.er

Attr. Total    Name
CPU
 sec.      %
============== Callers
1.661  39.15   JvmtiVTMSTransitionDisabler::VTMS_vthread_mount(_jobject*, bool)
1.351  31.84   JvmtiVTMSTransitionDisabler::VTMS_vthread_start(_jobject*)
1.231  29.01   SharedRuntime::notify_jvmti_vthread_unmount(oopDesc*, unsigned char, JavaThread*)

============== Stack Fragment
0.500  11.79   JvmtiVTMSTransitionDisabler::finish_VTMS_transition(_jobject*, bool)

============== Callees
2.972  70.05   java_lang_Thread::set_is_in_VTMS_transition(oopDesc*, bool)
0.350   8.25   JavaThread::set_is_in_VTMS_transition(bool)
0.340   8.02   __tls_get_addr
0.080   1.89   JNIHandles::resolve_external_guard(_jobject*)


The rest of the overhead (~10% of total overhead) is taken by calls to the function `java_lang_Thread::set_is_in_VTMS_transition()`. The plan is to address this in a separate fix. But it is expected to be a little?bit more tricky.

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

PR Comment: https://git.openjdk.org/jdk/pull/18937#issuecomment-2075566469

From mbaesken at openjdk.org  Thu Apr 25 12:49:33 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 25 Apr 2024 12:49:33 GMT
Subject: RFR: 8327769: jcmd GC.heap_dump without options should write to
 location given by -XX:HeapDumpPath, if set [v10]
In-Reply-To: <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>
Message-ID: <iEelSqy1RblGV1P7ZbvleyAjmy_VXVBtVR8rnGI7SFM=.d6033433-f486-4a67-b49e-4858436283fd@github.com>

On Wed, 27 Mar 2024 13:44:42 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently jcmd command GC.heap_dump only works with an additionally provided file name.
>> Syntax : GC.heap_dump [options] <filename>
>> 
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an additional mode where the <filename> is optional.
>> In case the filename is NOT set, we take the HeapDumpPath (file or directory);
>> 
>> new syntax :
>> GC.heap_dump [options] <filename> .. has precedence over second option
>> GC.heap_dump [options] ?in case -XX: HeapDumpPath=p is set
>> 
>> This would be a simplification e.g. for support cases where a filename or directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the path is intended/recommended for usage also in the jcmd case.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust java.1 man page

> It may be desirable to have VM.heap_dump support not specifying a filename and instead just have it choose a default name
> and path, probably the current working directory with a name something like java_pid.hprof.

So is there some intention to decide to have such a default now or in the near future ?
Otherwise it is a rather theoretical discussion .

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2077099599

From cjplummer at openjdk.org  Thu Apr 25 19:54:37 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 25 Apr 2024 19:54:37 GMT
Subject: RFR: 8327769: jcmd GC.heap_dump without options should write to
 location given by -XX:HeapDumpPath, if set [v10]
In-Reply-To: <iEelSqy1RblGV1P7ZbvleyAjmy_VXVBtVR8rnGI7SFM=.d6033433-f486-4a67-b49e-4858436283fd@github.com>
References: <Q3FS2GCGs1q5qZVvjYdiOt8Mo5fodcYwzAsrjAX-Szc=.387aea63-5c2b-44bf-8944-0c6c62582bd3@github.com>
 <yHC_H290jrPpwBva0X6EggLSAtzumxBCO51U6TE9cjY=.60102062-56d4-4dc0-a728-edcf27f4e716@github.com>
 <iEelSqy1RblGV1P7ZbvleyAjmy_VXVBtVR8rnGI7SFM=.d6033433-f486-4a67-b49e-4858436283fd@github.com>
Message-ID: <58VsdVFYcAj6V44QxfAv2wv3AbEfJAE9a2FD6dQAV3M=.4d76eaa5-6384-42fe-bfc5-ce82849f428e@github.com>

On Thu, 25 Apr 2024 12:46:53 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> So is there some intention to decide to have such a default now or in the near future ?
> Otherwise it is a rather theoretical discussion .

No decision on having a default has been made. My point was that implementing this PR equates to making a decision NOT to ever support a default. It doesn't leave it to be decided some time in the future.

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2078062419

From amenkov at openjdk.org  Thu Apr 25 21:04:35 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 25 Apr 2024 21:04:35 GMT
Subject: RFR: 8330969: scalability issue with loaded JVMTI agent
In-Reply-To: <FvcDTtfEpTjQmcSjEPSmKjpUloHElpk6uUPc7VPjc2U=.01a08d3f-5906-4429-9472-61218603f613@github.com>
References: <FvcDTtfEpTjQmcSjEPSmKjpUloHElpk6uUPc7VPjc2U=.01a08d3f-5906-4429-9472-61218603f613@github.com>
Message-ID: <mYXPmE3EJOVaM9CYMf8Ump5YFk9yMmldnv0xzjVqcWQ=.d4191382-1d7f-4598-a779-640da7990de9@github.com>

On Wed, 24 Apr 2024 16:04:30 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This is a fix of the following JVMTI scalability issue. A closed benchmark with millions of virtual threads shows 3X-4X overhead when a JVMTI agent has been loaded. For instance, this is observable when an app is executed under control of the Oracle Studio `collect` utility.
> For performance analysis, experiments and numbers, please, see the comment below this description.
> 
> The fix is to replace the global counter `_VTMS_transition_count` with the mark bit `_VTMS_transition_mark` in each `JavaThread`'.
> 
> Testing:
>  - Tested with mach5 tiers 1-6

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

> 1636:   // Iterates over all JavaThread's, counts VTMS transitions and restores
> 1637:   // jt->jvmti_thread_state() and jt->jvmti_vthread() for VTMS transition protocol.
> 1638:   void count_transitions_and_correct_jvmti_thread_states() {

The method doesn't count anything anymore.
Rename it to `correct_jvmti_thread_states()`?
Comment needs to be updated too.

src/hotspot/share/prims/jvmtiThreadState.cpp line 501:

> 499:   oop vt = JNIHandles::resolve_external_guard(vthread);
> 500:   java_lang_Thread::set_is_in_VTMS_transition(vt, false);
> 501:   assert(thread->VTMS_transition_mark(), "sanity ed_heck");

Suggestion:

  assert(thread->VTMS_transition_mark(), "sanity check");

src/hotspot/share/runtime/javaThread.hpp line 668:

> 666:   void toggle_is_disable_suspend()               { _is_disable_suspend = !_is_disable_suspend; };
> 667: 
> 668:   bool VTMS_transition_mark()                    { return Atomic::load(&_VTMS_transition_mark); }

Suggestion:

  bool VTMS_transition_mark() const              { return Atomic::load(&_VTMS_transition_mark); }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18937#discussion_r1580096556
PR Review Comment: https://git.openjdk.org/jdk/pull/18937#discussion_r1580101609
PR Review Comment: https://git.openjdk.org/jdk/pull/18937#discussion_r1580108674

From jjg at openjdk.org  Thu Apr 25 22:53:04 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 25 Apr 2024 22:53:04 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v8]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <l0Wf7Ng-zjDRAZwhsOY9wf2dytL6ctdsMmLCL3tkgdc=.670a964c-af86-4c75-9d5a-4f6e479ac598@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments # Please enter a commit message to explain why this merge is necessary, # especially if it merges an updated upstream into a topic branch. # # Lines starting with '#' will be ignored, and an empty message aborts # the
   commit.
 - Merge with upstream/master
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - Merge with upstream/master
 - update test
 - improve handling of ignorable doc comments
   suppress warning when building test code
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - call `saveDanglingDocComments` for local variable declarations
 - adjust call for `saveDanglingDocComments` for enum members
 - ... and 1 more: https://git.openjdk.org/jdk/compare/1c238d43...16a265a2

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

Changes: https://git.openjdk.org/jdk/pull/18527/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18527&range=07
  Stats: 485 lines in 59 files changed: 387 ins; 3 del; 95 mod
  Patch: https://git.openjdk.org/jdk/pull/18527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18527/head:pull/18527

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

From jjg at openjdk.org  Thu Apr 25 23:24:07 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 25 Apr 2024 23:24:07 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v9]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <be6kTtJezTLou_YPTgclvACoddoyffmpupwBjO2DIT8=.6cab77e8-c42a-4e22-9bcb-a8fea5cebf67@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  revert need to disable warning

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18527/files
  - new: https://git.openjdk.org/jdk/pull/18527/files/16a265a2..39689a52

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

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

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

From vromero at openjdk.org  Fri Apr 26 00:23:33 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 26 Apr 2024 00:23:33 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v9]
In-Reply-To: <be6kTtJezTLou_YPTgclvACoddoyffmpupwBjO2DIT8=.6cab77e8-c42a-4e22-9bcb-a8fea5cebf67@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
 <be6kTtJezTLou_YPTgclvACoddoyffmpupwBjO2DIT8=.6cab77e8-c42a-4e22-9bcb-a8fea5cebf67@github.com>
Message-ID: <txquEDIJ7YBKTZ6-EggzWEHSYzFxMXIBbwTuexdYXro=.af5bb232-dbd4-4099-9fc7-3bc22aacdd07@github.com>

On Thu, 25 Apr 2024 23:24:07 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
>> 
>> The work can be thought of as in 3 parts:
>> 
>> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
>> 
>> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
>> 
>>      *  Dangling documentation comments are handled as follows.
>>      *  1. {@code Scanner} adds all doc comments to a queue of
>>      *     recent doc comments. The queue is flushed whenever
>>      *     it is known that the recent doc comments should be
>>      *     ignored and should not cause any warnings.
>>      *  2. The primary documentation comment is the one obtained
>>      *     from the first token of any declaration.
>>      *     (using {@code token.getDocComment()}.
>>      *  3. At the end of the "signature" of the declaration
>>      *     (that is, before any initialization or body for the
>>      *     declaration) any other "recent" comments are saved
>>      *     in a map using the primary comment as a key,
>>      *     using this method, {@code saveDanglingComments}.
>>      *  4. When the tree node for the declaration is finally
>>      *     available, and the primary comment, if any,
>>      *     is "attached", (in {@link #attach}) any related
>>      *     dangling comments are also attached to the tree node
>>      *     by registering them using the {@link #deferredLintHandler}.
>>      *  5. (Later) Warnings may be genereated for the dangling
>>      *     comments, subject to the {@code -Xlint} and
>>      *     {@code @SuppressWarnings}.
>> 
>> 
>> 3.  Updates to the make files to disable the warnings in modules for which the 
>> warning is generated.  This is often because of the confusing use of `/**` to
>> create box or other standout comments.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert need to disable warning

looks good

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 583:

> 581:      *     dangling comments are also attached to the tree node
> 582:      *     by registering them using the {@link #deferredLintHandler}.
> 583:      *  5. (Later) Warnings may be genereated for the dangling

typo: generated

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18527#pullrequestreview-2023792395
PR Review Comment: https://git.openjdk.org/jdk/pull/18527#discussion_r1580263826

From sspitsyn at openjdk.org  Fri Apr 26 07:42:34 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 26 Apr 2024 07:42:34 GMT
Subject: RFR: 8330969: scalability issue with loaded JVMTI agent
In-Reply-To: <mYXPmE3EJOVaM9CYMf8Ump5YFk9yMmldnv0xzjVqcWQ=.d4191382-1d7f-4598-a779-640da7990de9@github.com>
References: <FvcDTtfEpTjQmcSjEPSmKjpUloHElpk6uUPc7VPjc2U=.01a08d3f-5906-4429-9472-61218603f613@github.com>
 <mYXPmE3EJOVaM9CYMf8Ump5YFk9yMmldnv0xzjVqcWQ=.d4191382-1d7f-4598-a779-640da7990de9@github.com>
Message-ID: <10TDSa0b4qQ2SfJPTvgPsQxK9jq3EKUQgHQTdHaHazg=.a9607741-95ad-40c8-9c15-f38c9cd51769@github.com>

On Thu, 25 Apr 2024 20:39:03 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> This is a fix of the following JVMTI scalability issue. A closed benchmark with millions of virtual threads shows 3X-4X overhead when a JVMTI agent has been loaded. For instance, this is observable when an app is executed under control of the Oracle Studio `collect` utility.
>> For performance analysis, experiments and numbers, please, see the comment below this description.
>> 
>> The fix is to replace the global counter `_VTMS_transition_count` with the mark bit `_VTMS_transition_mark` in each `JavaThread`'.
>> 
>> Testing:
>>  - Tested with mach5 tiers 1-6
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1638:
> 
>> 1636:   // Iterates over all JavaThread's, counts VTMS transitions and restores
>> 1637:   // jt->jvmti_thread_state() and jt->jvmti_vthread() for VTMS transition protocol.
>> 1638:   void count_transitions_and_correct_jvmti_thread_states() {
> 
> The method doesn't count anything anymore.
> Rename it to `correct_jvmti_thread_states()`?
> Comment needs to be updated too.

Good suggestion, thanks. Renamed function and corrected the comment.

> src/hotspot/share/prims/jvmtiThreadState.cpp line 501:
> 
>> 499:   oop vt = JNIHandles::resolve_external_guard(vthread);
>> 500:   java_lang_Thread::set_is_in_VTMS_transition(vt, false);
>> 501:   assert(thread->VTMS_transition_mark(), "sanity ed_heck");
> 
> Suggestion:
> 
>   assert(thread->VTMS_transition_mark(), "sanity check");

Thanks. Fixed now.

> src/hotspot/share/runtime/javaThread.hpp line 668:
> 
>> 666:   void toggle_is_disable_suspend()               { _is_disable_suspend = !_is_disable_suspend; };
>> 667: 
>> 668:   bool VTMS_transition_mark()                    { return Atomic::load(&_VTMS_transition_mark); }
> 
> Suggestion:
> 
>   bool VTMS_transition_mark() const              { return Atomic::load(&_VTMS_transition_mark); }

Good suggestion, thanks. Fixed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18937#discussion_r1580607373
PR Review Comment: https://git.openjdk.org/jdk/pull/18937#discussion_r1580610256
PR Review Comment: https://git.openjdk.org/jdk/pull/18937#discussion_r1580612160

From sspitsyn at openjdk.org  Fri Apr 26 07:45:50 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 26 Apr 2024 07:45:50 GMT
Subject: RFR: 8330969: scalability issue with loaded JVMTI agent [v2]
In-Reply-To: <FvcDTtfEpTjQmcSjEPSmKjpUloHElpk6uUPc7VPjc2U=.01a08d3f-5906-4429-9472-61218603f613@github.com>
References: <FvcDTtfEpTjQmcSjEPSmKjpUloHElpk6uUPc7VPjc2U=.01a08d3f-5906-4429-9472-61218603f613@github.com>
Message-ID: <XkAPnKpNsajt7wuCSz_05DMueqXM2taByHw0_mS1vXo=.9d0bc5f7-f32d-4778-b334-4adc51e4deea@github.com>

> This is a fix of the following JVMTI scalability issue. A closed benchmark with millions of virtual threads shows 3X-4X overhead when a JVMTI agent has been loaded. For instance, this is observable when an app is executed under control of the Oracle Studio `collect` utility.
> For performance analysis, experiments and numbers, please, see the comment below this description.
> 
> The fix is to replace the global counter `_VTMS_transition_count` with the mark bit `_VTMS_transition_mark` in each `JavaThread`'.
> 
> Testing:
>  - Tested with mach5 tiers 1-6

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

  review: fixed minor issues: renamed function, corrected comment, removed typo in assert

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18937/files
  - new: https://git.openjdk.org/jdk/pull/18937/files/6e1bf369..03bcfecb

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

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

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

From jjg at openjdk.org  Fri Apr 26 16:04:09 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 26 Apr 2024 16:04:09 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v10]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <WA4RKekV8mLqnrxi1HqfCR2F6DT27mqVdLhigmerCtA=.33dcb72a-f3ff-4d9a-a794-95ff3849e5fa@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  fix typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18527/files
  - new: https://git.openjdk.org/jdk/pull/18527/files/39689a52..48e8b0a2

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

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

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

From prr at openjdk.org  Fri Apr 26 19:34:00 2024
From: prr at openjdk.org (Phil Race)
Date: Fri, 26 Apr 2024 19:34:00 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v10]
In-Reply-To: <WA4RKekV8mLqnrxi1HqfCR2F6DT27mqVdLhigmerCtA=.33dcb72a-f3ff-4d9a-a794-95ff3849e5fa@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
 <WA4RKekV8mLqnrxi1HqfCR2F6DT27mqVdLhigmerCtA=.33dcb72a-f3ff-4d9a-a794-95ff3849e5fa@github.com>
Message-ID: <SD0S716mdRSViTfaViQgFYEkmR7WmBalQQe3_FI7VQc=.b83407a8-0c84-4ed9-8b56-adf6db1a2e0c@github.com>

On Fri, 26 Apr 2024 16:04:09 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
>> 
>> The work can be thought of as in 3 parts:
>> 
>> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
>> 
>> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
>> 
>>      *  Dangling documentation comments are handled as follows.
>>      *  1. {@code Scanner} adds all doc comments to a queue of
>>      *     recent doc comments. The queue is flushed whenever
>>      *     it is known that the recent doc comments should be
>>      *     ignored and should not cause any warnings.
>>      *  2. The primary documentation comment is the one obtained
>>      *     from the first token of any declaration.
>>      *     (using {@code token.getDocComment()}.
>>      *  3. At the end of the "signature" of the declaration
>>      *     (that is, before any initialization or body for the
>>      *     declaration) any other "recent" comments are saved
>>      *     in a map using the primary comment as a key,
>>      *     using this method, {@code saveDanglingComments}.
>>      *  4. When the tree node for the declaration is finally
>>      *     available, and the primary comment, if any,
>>      *     is "attached", (in {@link #attach}) any related
>>      *     dangling comments are also attached to the tree node
>>      *     by registering them using the {@link #deferredLintHandler}.
>>      *  5. (Later) Warnings may be genereated for the dangling
>>      *     comments, subject to the {@code -Xlint} and
>>      *     {@code @SuppressWarnings}.
>> 
>> 
>> 3.  Updates to the make files to disable the warnings in modules for which the 
>> warning is generated.  This is often because of the confusing use of `/**` to
>> create box or other standout comments.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18527#pullrequestreview-2025744069

From jjg at openjdk.org  Fri Apr 26 19:49:56 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 26 Apr 2024 19:49:56 GMT
Subject: Integrated: 8303689: javac -Xlint could/should report on "dangling"
 doc comments
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <jz5iSs8rS6B9ZP2l3HbT7UR9gdQiXvxyQFGqikRLN7U=.584799e9-55c0-4a22-b62f-e30406cfe8ea@github.com>

On Wed, 27 Mar 2024 22:04:30 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

This pull request has now been integrated.

Changeset: a920af23
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a920af233a11592af113f456f7608cb59dd1617e
Stats:     482 lines in 58 files changed: 385 ins; 3 del; 94 mod

8303689: javac -Xlint could/should report on "dangling" doc comments

Reviewed-by: vromero, ihse, prr

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

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

From cjplummer at openjdk.org  Fri Apr 26 20:03:50 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 26 Apr 2024 20:03:50 GMT
Subject: RFR: 8330969: scalability issue with loaded JVMTI agent [v2]
In-Reply-To: <XkAPnKpNsajt7wuCSz_05DMueqXM2taByHw0_mS1vXo=.9d0bc5f7-f32d-4778-b334-4adc51e4deea@github.com>
References: <FvcDTtfEpTjQmcSjEPSmKjpUloHElpk6uUPc7VPjc2U=.01a08d3f-5906-4429-9472-61218603f613@github.com>
 <XkAPnKpNsajt7wuCSz_05DMueqXM2taByHw0_mS1vXo=.9d0bc5f7-f32d-4778-b334-4adc51e4deea@github.com>
Message-ID: <f-SKLHRYrAIwMR9tGth-_BsschetH2jMiXS0kx_ORD4=.3f61ca66-61d4-4f8d-9233-b01d852ae846@github.com>

On Fri, 26 Apr 2024 07:45:50 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is a fix of the following JVMTI scalability issue. A closed benchmark with millions of virtual threads shows 3X-4X overhead when a JVMTI agent has been loaded. For instance, this is observable when an app is executed under control of the Oracle Studio `collect` utility.
>> For performance analysis, experiments and numbers, please, see the comment below this description.
>> 
>> The fix is to replace the global counter `_VTMS_transition_count` with the mark bit `_VTMS_transition_mark` in each `JavaThread`'.
>> 
>> Testing:
>>  - Tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: fixed minor issues: renamed function, corrected comment, removed typo in assert

src/hotspot/share/prims/jvmtiThreadState.cpp line 366:

> 364:           attempts--;
> 365:         }
> 366:         DEBUG_ONLY(if (attempts == 0) break;)

Previously `_VTMS_transition_count` considered all threads at the same time. Now you are iterating through the threads and looking at a flag in each one. Is it guaranteed that once the `_VTMS_transition_mark` flag has been verified not to be set in a thread it won't get set while still iterating in the threads loop?

src/hotspot/share/prims/jvmtiThreadState.cpp line 433:

> 431:   // Avoid using MonitorLocker on performance critical path, use
> 432:   // two-level synchronization with lock-free operations on counters.
> 433:   assert(!thread->VTMS_transition_mark(), "sanity check");

The "counters" comment needs to be updated.

src/hotspot/share/prims/jvmtiThreadState.cpp line 456:

> 454:     // Slow path: undo unsuccessful optimistic counter incrementation.
> 455:     // It can cause an extra waiting cycle for VTMS transition disablers.
> 456:     thread->set_VTMS_transition_mark(false);

The "optimistic counter incrementation" comment needs updating.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18937#discussion_r1581460754
PR Review Comment: https://git.openjdk.org/jdk/pull/18937#discussion_r1581463641
PR Review Comment: https://git.openjdk.org/jdk/pull/18937#discussion_r1581462878

From kvn at openjdk.org  Fri Apr 26 21:20:55 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 26 Apr 2024 21:20:55 GMT
Subject: RFR: 8331087: Move immutable nmethod data from CodeCache
Message-ID: <ineXbCWnnv5cRobzHW2TZVCIq8wuV8pPZ1PEn7-5yGg=.ba55a4e9-ced5-473f-8801-05e2d4efc495@github.com>

Move immutable nmethod's data from CodeCache to C heap. It includes `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data, speculations, jvmci_data`. It amounts for about 30% (optimized VM) of space in CodeCache.

Use HotSpot's `os::malloc()` to allocate memory in C heap for immutable nmethod's data. Bail out compilation if allocation failed.

Shuffle fields order and change some fields size from 4 to 2 bytes to avoid nmethod's header size increase.

Tested tier1-5, stress,xcomp

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

Commit messages:
 - 8331087: Move immutable nmethod data from CodeCache

Changes: https://git.openjdk.org/jdk/pull/18984/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18984&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331087
  Stats: 290 lines in 7 files changed: 149 ins; 31 del; 110 mod
  Patch: https://git.openjdk.org/jdk/pull/18984.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18984/head:pull/18984

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

From kvn at openjdk.org  Fri Apr 26 21:47:58 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 26 Apr 2024 21:47:58 GMT
Subject: RFR: 8331087: Move immutable nmethod data from CodeCache
In-Reply-To: <ineXbCWnnv5cRobzHW2TZVCIq8wuV8pPZ1PEn7-5yGg=.ba55a4e9-ced5-473f-8801-05e2d4efc495@github.com>
References: <ineXbCWnnv5cRobzHW2TZVCIq8wuV8pPZ1PEn7-5yGg=.ba55a4e9-ced5-473f-8801-05e2d4efc495@github.com>
Message-ID: <lnmxuWVwHZ_Lltth9rCIBVSyeY5jmNdC_iovLBj54z4=.12c5f257-114c-4306-ac74-1a97b2c2b3ad@github.com>

On Fri, 26 Apr 2024 21:16:03 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Move immutable nmethod's data from CodeCache to C heap. It includes `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data, speculations, jvmci_data`. It amounts for about 30% (optimized VM) of space in CodeCache.
> 
> Use HotSpot's `os::malloc()` to allocate memory in C heap for immutable nmethod's data. Bail out compilation if allocation failed.
> 
> Shuffle fields order and change some fields size from 4 to 2 bytes to avoid nmethod's header size increase.
> 
> Tested tier1-5, stress,xcomp

src/hotspot/share/code/nmethod.cpp line 117:

> 115:   result = static_cast<T>(thing); \
> 116:   assert(static_cast<int>(result) == thing, "failed: %d != %d", static_cast<int>(result), thing);
> 117: 

I replaced `checked_cast<>()` with this macro because of next issues:
 - The existing assert points to `utilities/checkedCast.hpp` file where this method is located and not where failed cast. It does not help when it is used several times in one method (for example, in `nmethod()` constructors).
 - The existing assert does not print values

src/hotspot/share/code/nmethod.cpp line 1324:

> 1322: 
> 1323:     // native wrapper does not have read-only data but we need unique not null address
> 1324:     _immutable_data          = data_end();

I can't use nullptr because VM expects not null address when it checks, for example, `dependencies_begin()` even so sizes are 0.
I used `data_end()` instead of nullptr in other places too.

src/hotspot/share/code/nmethod.hpp line 583:

> 581:   int dependencies_size  () const { return int(          dependencies_end () -           dependencies_begin ()); }
> 582:   int handler_table_size () const { return int(          handler_table_end() -           handler_table_begin()); }
> 583:   int nul_chk_table_size () const { return int(          nul_chk_table_end() -           nul_chk_table_begin()); }

Shift by one space to aline code.

test/hotspot/jtreg/compiler/c1/TestLinearScanOrderMain.java line 29:

> 27:  * @compile TestLinearScanOrder.jasm
> 28:  * @run main/othervm -Xcomp -XX:+TieredCompilation -XX:TieredStopAtLevel=1
> 29:  *                   -XX:+IgnoreUnrecognizedVMOptions -XX:NMethodSizeLimit=655360

This test caught one `check_cast<>` issue during development but only on aarch64.
On x64 the test bailed out compilation before that because default `NMethodSizeLimit` was not big enough ((64*K)*wordSize = 524288).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18984#discussion_r1581561933
PR Review Comment: https://git.openjdk.org/jdk/pull/18984#discussion_r1581565762
PR Review Comment: https://git.openjdk.org/jdk/pull/18984#discussion_r1581558637
PR Review Comment: https://git.openjdk.org/jdk/pull/18984#discussion_r1581557756

From amenkov at openjdk.org  Fri Apr 26 23:06:23 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 26 Apr 2024 23:06:23 GMT
Subject: RFR: 8330852: All callers of
 JvmtiEnvBase::get_threadOop_and_JavaThread should pass current thread
 explicitly
Message-ID: <HHDWPZJogKzfDNvS2dJ2xxUKh9w0-qYtM5tiSUjCBdk=.342df145-c872-455d-b65e-f5c8b729e781@github.com>

Some cleanup related to JvmtiEnvBase::get_threadOop_and_JavaThread method

Testing: tier1-6

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

Commit messages:
 - fix

Changes: https://git.openjdk.org/jdk/pull/18986/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18986&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330852
  Stats: 42 lines in 3 files changed: 3 ins; 10 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/18986.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18986/head:pull/18986

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

From cjplummer at openjdk.org  Fri Apr 26 23:41:06 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 26 Apr 2024 23:41:06 GMT
Subject: RFR: 8330852: All callers of
 JvmtiEnvBase::get_threadOop_and_JavaThread should pass current thread
 explicitly
In-Reply-To: <HHDWPZJogKzfDNvS2dJ2xxUKh9w0-qYtM5tiSUjCBdk=.342df145-c872-455d-b65e-f5c8b729e781@github.com>
References: <HHDWPZJogKzfDNvS2dJ2xxUKh9w0-qYtM5tiSUjCBdk=.342df145-c872-455d-b65e-f5c8b729e781@github.com>
Message-ID: <zJDP5yOYfBRaNXFcNaxW7grk5cA_ry_ZTEnE3a2YNyg=.64f9ace6-db9e-42b5-af81-ed7acac2269c@github.com>

On Fri, 26 Apr 2024 22:59:43 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Some cleanup related to JvmtiEnvBase::get_threadOop_and_JavaThread method
> 
> Testing: tier1-6

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

> 1974:   oop thread_obj = nullptr;
> 1975: 
> 1976:   jvmtiError err = JvmtiEnvBase::get_threadOop_and_JavaThread(tlh.list(), target, current, &java_thread, &thread_obj);

I think a good cleanup would be to also replace `current` with `current_thread`, although I'm not sure how common each are. I see 3 `current` references in this webrev.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18986#discussion_r1581610079

From amenkov at openjdk.org  Sat Apr 27 00:04:05 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Sat, 27 Apr 2024 00:04:05 GMT
Subject: RFR: 8330852: All callers of
 JvmtiEnvBase::get_threadOop_and_JavaThread should pass current thread
 explicitly
In-Reply-To: <zJDP5yOYfBRaNXFcNaxW7grk5cA_ry_ZTEnE3a2YNyg=.64f9ace6-db9e-42b5-af81-ed7acac2269c@github.com>
References: <HHDWPZJogKzfDNvS2dJ2xxUKh9w0-qYtM5tiSUjCBdk=.342df145-c872-455d-b65e-f5c8b729e781@github.com>
 <zJDP5yOYfBRaNXFcNaxW7grk5cA_ry_ZTEnE3a2YNyg=.64f9ace6-db9e-42b5-af81-ed7acac2269c@github.com>
Message-ID: <SREtir9aP4YOBYbn6pXv-d2Mt9JA20_g9bL0WeTKMys=.7f9b8413-0689-4820-a2f0-871692fd51ee@github.com>

On Fri, 26 Apr 2024 23:36:41 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Some cleanup related to JvmtiEnvBase::get_threadOop_and_JavaThread method
>> 
>> Testing: tier1-6
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1976:
> 
>> 1974:   oop thread_obj = nullptr;
>> 1975: 
>> 1976:   jvmtiError err = JvmtiEnvBase::get_threadOop_and_JavaThread(tlh.list(), target, current, &java_thread, &thread_obj);
> 
> I think a good cleanup would be to also replace `current` with `current_thread`, although I'm not sure how common each are. I see 3 `current` references in this webrev.

Looks like in JVMTI `current_thread` is more common (and `current` is usually used in runtime :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18986#discussion_r1581628063

From dlong at openjdk.org  Sat Apr 27 00:05:12 2024
From: dlong at openjdk.org (Dean Long)
Date: Sat, 27 Apr 2024 00:05:12 GMT
Subject: RFR: 8331087: Move immutable nmethod data from CodeCache
In-Reply-To: <lnmxuWVwHZ_Lltth9rCIBVSyeY5jmNdC_iovLBj54z4=.12c5f257-114c-4306-ac74-1a97b2c2b3ad@github.com>
References: <ineXbCWnnv5cRobzHW2TZVCIq8wuV8pPZ1PEn7-5yGg=.ba55a4e9-ced5-473f-8801-05e2d4efc495@github.com>
 <lnmxuWVwHZ_Lltth9rCIBVSyeY5jmNdC_iovLBj54z4=.12c5f257-114c-4306-ac74-1a97b2c2b3ad@github.com>
Message-ID: <5wDjPMjtjkFLL6V4UtPQMeLLlIZWyPGmoHf20NvHLRc=.649977ed-329d-4355-8188-71c8d5c7c14f@github.com>

On Fri, 26 Apr 2024 21:36:50 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Move immutable nmethod's data from CodeCache to C heap. It includes `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data, speculations, jvmci_data`. It amounts for about 30% (optimized VM) of space in CodeCache.
>> 
>> Use HotSpot's `os::malloc()` to allocate memory in C heap for immutable nmethod's data. Bail out compilation if allocation failed.
>> 
>> Shuffle fields order and change some fields size from 4 to 2 bytes to avoid nmethod's header size increase.
>> 
>> Tested tier1-5, stress,xcomp
>> 
>> Our performance testing does not show difference.
>> 
>> Example of updated `-XX:+PrintNMethodStatistics` output is in JBS comment.
>
> src/hotspot/share/code/nmethod.cpp line 117:
> 
>> 115:   result = static_cast<T>(thing); \
>> 116:   assert(static_cast<int>(result) == thing, "failed: %d != %d", static_cast<int>(result), thing);
>> 117: 
> 
> I replaced `checked_cast<>()` with this macro because of next issues:
>  - The existing assert points to `utilities/checkedCast.hpp` file where this method is located and not where failed cast. It does not help when it is used several times in one method (for example, in `nmethod()` constructors).
>  - The existing assert does not print values

I thought @kimbarrett had a draft PR to address the error reporting issue, but I can't seem to find it.  To solve the general problem, I think we need a version of vmassert() that takes `char* file, int lineno` as arguments, and a macro wrapper for checked_cast() that passes `__FILE__` and `__LINEN__` from the caller.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18984#discussion_r1581628786

From kvn at openjdk.org  Sat Apr 27 00:45:10 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 27 Apr 2024 00:45:10 GMT
Subject: RFR: 8331087: Move immutable nmethod data from CodeCache
In-Reply-To: <5wDjPMjtjkFLL6V4UtPQMeLLlIZWyPGmoHf20NvHLRc=.649977ed-329d-4355-8188-71c8d5c7c14f@github.com>
References: <ineXbCWnnv5cRobzHW2TZVCIq8wuV8pPZ1PEn7-5yGg=.ba55a4e9-ced5-473f-8801-05e2d4efc495@github.com>
 <lnmxuWVwHZ_Lltth9rCIBVSyeY5jmNdC_iovLBj54z4=.12c5f257-114c-4306-ac74-1a97b2c2b3ad@github.com>
 <5wDjPMjtjkFLL6V4UtPQMeLLlIZWyPGmoHf20NvHLRc=.649977ed-329d-4355-8188-71c8d5c7c14f@github.com>
Message-ID: <sSdNuE6d8kXCNPsn74Y76lNES2bJKjoKKy8XosDKhGI=.4c65e0ad-d8e9-4128-9aaa-cf66b8ba22de@github.com>

On Sat, 27 Apr 2024 00:02:16 GMT, Dean Long <dlong at openjdk.org> wrote:

>> src/hotspot/share/code/nmethod.cpp line 117:
>> 
>>> 115:   result = static_cast<T>(thing); \
>>> 116:   assert(static_cast<int>(result) == thing, "failed: %d != %d", static_cast<int>(result), thing);
>>> 117: 
>> 
>> I replaced `checked_cast<>()` with this macro because of next issues:
>>  - The existing assert points to `utilities/checkedCast.hpp` file where this method is located and not where failed cast. It does not help when it is used several times in one method (for example, in `nmethod()` constructors).
>>  - The existing assert does not print values
>
> I thought @kimbarrett had a draft PR to address the error reporting issue, but I can't seem to find it.  To solve the general problem, I think we need a version of vmassert() that takes `char* file, int lineno` as arguments, and a macro wrapper for checked_cast() that passes `__FILE__` and `__LINEN__` from the caller.

Yes, it would be perfect separate RFE.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18984#discussion_r1581641784

From dlong at openjdk.org  Sat Apr 27 00:51:14 2024
From: dlong at openjdk.org (Dean Long)
Date: Sat, 27 Apr 2024 00:51:14 GMT
Subject: RFR: 8331087: Move immutable nmethod data from CodeCache
In-Reply-To: <ineXbCWnnv5cRobzHW2TZVCIq8wuV8pPZ1PEn7-5yGg=.ba55a4e9-ced5-473f-8801-05e2d4efc495@github.com>
References: <ineXbCWnnv5cRobzHW2TZVCIq8wuV8pPZ1PEn7-5yGg=.ba55a4e9-ced5-473f-8801-05e2d4efc495@github.com>
Message-ID: <MBPA-UKcK1zc9XQAD6i1fK8_nWneS3fVPidex2PpRrk=.6a823220-4fd4-49c2-ae65-384b32716c45@github.com>

On Fri, 26 Apr 2024 21:16:03 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Move immutable nmethod's data from CodeCache to C heap. It includes `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data, speculations, jvmci_data`. It amounts for about 30% (optimized VM) of space in CodeCache.
> 
> Use HotSpot's `os::malloc()` to allocate memory in C heap for immutable nmethod's data. Bail out compilation if allocation failed.
> 
> Shuffle fields order and change some fields size from 4 to 2 bytes to avoid nmethod's header size increase.
> 
> Tested tier1-5, stress,xcomp
> 
> Our performance testing does not show difference.
> 
> Example of updated `-XX:+PrintNMethodStatistics` output is in JBS comment.

src/hotspot/share/code/nmethod.cpp line 1332:

> 1330: #if INCLUDE_JVMCI
> 1331:     _speculations_offset     = _scopes_data_offset;
> 1332:     _jvmci_data_offset       = _speculations_offset;

Why not use 0 for all these?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18984#discussion_r1581642931

From dlong at openjdk.org  Sat Apr 27 00:56:04 2024
From: dlong at openjdk.org (Dean Long)
Date: Sat, 27 Apr 2024 00:56:04 GMT
Subject: RFR: 8331087: Move immutable nmethod data from CodeCache
In-Reply-To: <ineXbCWnnv5cRobzHW2TZVCIq8wuV8pPZ1PEn7-5yGg=.ba55a4e9-ced5-473f-8801-05e2d4efc495@github.com>
References: <ineXbCWnnv5cRobzHW2TZVCIq8wuV8pPZ1PEn7-5yGg=.ba55a4e9-ced5-473f-8801-05e2d4efc495@github.com>
Message-ID: <kjRW2-WHhsDOlO3gehjY49VT-S50aX-ZsP7tVw7LyxE=.7ff3480d-cf26-4612-8116-fa3abaa60a1b@github.com>

On Fri, 26 Apr 2024 21:16:03 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Move immutable nmethod's data from CodeCache to C heap. It includes `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data, speculations, jvmci_data`. It amounts for about 30% (optimized VM) of space in CodeCache.
> 
> Use HotSpot's `os::malloc()` to allocate memory in C heap for immutable nmethod's data. Bail out compilation if allocation failed.
> 
> Shuffle fields order and change some fields size from 4 to 2 bytes to avoid nmethod's header size increase.
> 
> Tested tier1-5, stress,xcomp
> 
> Our performance testing does not show difference.
> 
> Example of updated `-XX:+PrintNMethodStatistics` output is in JBS comment.

src/hotspot/share/code/nmethod.cpp line 1484:

> 1482:       // Calculate positive offset as distance between the start of stubs section
> 1483:       // (which is also the end of instructions section) and the start of the handler.
> 1484:       CHECKED_CAST(_unwind_handler_offset, int16_t, (_stub_offset - code_offset() - offsets->value(CodeOffsets::UnwindHandler)));

Suggestion:

      int unwind_handler_offset = code_offset() + offsets->value(CodeOffsets::UnwindHandler);
      CHECKED_CAST(_unwind_handler_offset, int16_t, _stub_offset - unwind_handler_offset);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18984#discussion_r1581644356

From kvn at openjdk.org  Sat Apr 27 01:15:03 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 27 Apr 2024 01:15:03 GMT
Subject: RFR: 8331087: Move immutable nmethod data from CodeCache
In-Reply-To: <ineXbCWnnv5cRobzHW2TZVCIq8wuV8pPZ1PEn7-5yGg=.ba55a4e9-ced5-473f-8801-05e2d4efc495@github.com>
References: <ineXbCWnnv5cRobzHW2TZVCIq8wuV8pPZ1PEn7-5yGg=.ba55a4e9-ced5-473f-8801-05e2d4efc495@github.com>
Message-ID: <Hqr0jbAmg4RoWQvOQrY6sCT3OcgmBKv-nR2-EaDtM4s=.e1b3c573-c8f9-49f8-ace7-929eefebd2d6@github.com>

On Fri, 26 Apr 2024 21:16:03 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Move immutable nmethod's data from CodeCache to C heap. It includes `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data, speculations, jvmci_data`. It amounts for about 30% (optimized VM) of space in CodeCache.
> 
> Use HotSpot's `os::malloc()` to allocate memory in C heap for immutable nmethod's data. Bail out compilation if allocation failed.
> 
> Shuffle fields order and change some fields size from 4 to 2 bytes to avoid nmethod's header size increase.
> 
> Tested tier1-5, stress,xcomp
> 
> Our performance testing does not show difference.
> 
> Example of updated `-XX:+PrintNMethodStatistics` output is in JBS comment.

Thank you, @dean-long, for review. I will collect (hopefully) more comments for next update before testing and pushing it.

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

PR Comment: https://git.openjdk.org/jdk/pull/18984#issuecomment-2080291257

From kvn at openjdk.org  Sat Apr 27 01:15:05 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 27 Apr 2024 01:15:05 GMT
Subject: RFR: 8331087: Move immutable nmethod data from CodeCache
In-Reply-To: <MBPA-UKcK1zc9XQAD6i1fK8_nWneS3fVPidex2PpRrk=.6a823220-4fd4-49c2-ae65-384b32716c45@github.com>
References: <ineXbCWnnv5cRobzHW2TZVCIq8wuV8pPZ1PEn7-5yGg=.ba55a4e9-ced5-473f-8801-05e2d4efc495@github.com>
 <MBPA-UKcK1zc9XQAD6i1fK8_nWneS3fVPidex2PpRrk=.6a823220-4fd4-49c2-ae65-384b32716c45@github.com>
Message-ID: <xtnyOStRsQregpfvEKMzDds6sqAyZSBAV6O3ZsZE6UU=.be939524-9ce9-4184-b1c6-c4ecfd46f340@github.com>

On Sat, 27 Apr 2024 00:48:49 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Move immutable nmethod's data from CodeCache to C heap. It includes `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data, speculations, jvmci_data`. It amounts for about 30% (optimized VM) of space in CodeCache.
>> 
>> Use HotSpot's `os::malloc()` to allocate memory in C heap for immutable nmethod's data. Bail out compilation if allocation failed.
>> 
>> Shuffle fields order and change some fields size from 4 to 2 bytes to avoid nmethod's header size increase.
>> 
>> Tested tier1-5, stress,xcomp
>> 
>> Our performance testing does not show difference.
>> 
>> Example of updated `-XX:+PrintNMethodStatistics` output is in JBS comment.
>
> src/hotspot/share/code/nmethod.cpp line 1332:
> 
>> 1330: #if INCLUDE_JVMCI
>> 1331:     _speculations_offset     = _scopes_data_offset;
>> 1332:     _jvmci_data_offset       = _speculations_offset;
> 
> Why not use 0 for all these?

Right. Before all these offsets were assigned to _dependencies_offset which was not 0.
But now we can use 0 for all of them since "_dependencies_offset" is 0.

> src/hotspot/share/code/nmethod.cpp line 1484:
> 
>> 1482:       // Calculate positive offset as distance between the start of stubs section
>> 1483:       // (which is also the end of instructions section) and the start of the handler.
>> 1484:       CHECKED_CAST(_unwind_handler_offset, int16_t, (_stub_offset - code_offset() - offsets->value(CodeOffsets::UnwindHandler)));
> 
> Suggestion:
> 
>       int unwind_handler_offset = code_offset() + offsets->value(CodeOffsets::UnwindHandler);
>       CHECKED_CAST(_unwind_handler_offset, int16_t, _stub_offset - unwind_handler_offset);

Will do.

> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/NMethod.java line 528:
> 
>> 526:   private int getScopesDataOffset()   { return (int) scopesDataOffsetField  .getValue(addr); }
>> 527:   private int getScopesPCsOffset()    { return (int) scopesPCsOffsetField   .getValue(addr); }
>> 528:   private int getDependenciesOffset() { return (int) 0; }
> 
> Suggestion:
> 
> 
> No longer used.

Will remove.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18984#discussion_r1581667051
PR Review Comment: https://git.openjdk.org/jdk/pull/18984#discussion_r1581668080
PR Review Comment: https://git.openjdk.org/jdk/pull/18984#discussion_r1581679317

From dlong at openjdk.org  Sat Apr 27 01:15:05 2024
From: dlong at openjdk.org (Dean Long)
Date: Sat, 27 Apr 2024 01:15:05 GMT
Subject: RFR: 8331087: Move immutable nmethod data from CodeCache
In-Reply-To: <ineXbCWnnv5cRobzHW2TZVCIq8wuV8pPZ1PEn7-5yGg=.ba55a4e9-ced5-473f-8801-05e2d4efc495@github.com>
References: <ineXbCWnnv5cRobzHW2TZVCIq8wuV8pPZ1PEn7-5yGg=.ba55a4e9-ced5-473f-8801-05e2d4efc495@github.com>
Message-ID: <sqxgNGrnBwRHC09cyQ44uxSbGkm_M98qiFSCv00pcis=.947952e7-5aeb-44f6-87da-2b260c424014@github.com>

On Fri, 26 Apr 2024 21:16:03 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Move immutable nmethod's data from CodeCache to C heap. It includes `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data, speculations, jvmci_data`. It amounts for about 30% (optimized VM) of space in CodeCache.
> 
> Use HotSpot's `os::malloc()` to allocate memory in C heap for immutable nmethod's data. Bail out compilation if allocation failed.
> 
> Shuffle fields order and change some fields size from 4 to 2 bytes to avoid nmethod's header size increase.
> 
> Tested tier1-5, stress,xcomp
> 
> Our performance testing does not show difference.
> 
> Example of updated `-XX:+PrintNMethodStatistics` output is in JBS comment.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/NMethod.java line 528:

> 526:   private int getScopesDataOffset()   { return (int) scopesDataOffsetField  .getValue(addr); }
> 527:   private int getScopesPCsOffset()    { return (int) scopesPCsOffsetField   .getValue(addr); }
> 528:   private int getDependenciesOffset() { return (int) 0; }

Suggestion:


No longer used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18984#discussion_r1581671710

From duke at openjdk.org  Sat Apr 27 02:34:21 2024
From: duke at openjdk.org (Lei Zaakjyu)
Date: Sat, 27 Apr 2024 02:34:21 GMT
Subject: RFR: 8330694: Rename 'HeapRegion' to 'G1HeapRegion' [v4]
In-Reply-To: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
Message-ID: <tKoc_1Z7ZAN6YuR_BpkrbOMi54UoDk0WYeHHK5aE3XE=.0ca685db-af09-4885-89ee-e35b0e9cf2b8@github.com>

> follow up 8267941

Lei Zaakjyu has updated the pull request incrementally with one additional commit since the last revision:

  fix indentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18871/files
  - new: https://git.openjdk.org/jdk/pull/18871/files/f02334fd..a76a71de

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

  Stats: 34 lines in 8 files changed: 0 ins; 2 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/18871.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18871/head:pull/18871

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

From dnsimon at openjdk.org  Sat Apr 27 20:51:14 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Sat, 27 Apr 2024 20:51:14 GMT
Subject: RFR: 8331087: Move immutable nmethod data from CodeCache
In-Reply-To: <ineXbCWnnv5cRobzHW2TZVCIq8wuV8pPZ1PEn7-5yGg=.ba55a4e9-ced5-473f-8801-05e2d4efc495@github.com>
References: <ineXbCWnnv5cRobzHW2TZVCIq8wuV8pPZ1PEn7-5yGg=.ba55a4e9-ced5-473f-8801-05e2d4efc495@github.com>
Message-ID: <BTVobrnBD1mUXws4QI_rtbups-orMbBBSnRfCNvTm-Y=.fde9f3b3-63ce-474c-9861-9628664cba05@github.com>

On Fri, 26 Apr 2024 21:16:03 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Move immutable nmethod's data from CodeCache to C heap. It includes `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data, speculations, jvmci_data`. It amounts for about 30% (optimized VM) of space in CodeCache.
> 
> Use HotSpot's `os::malloc()` to allocate memory in C heap for immutable nmethod's data. Bail out compilation if allocation failed.
> 
> Shuffle fields order and change some fields size from 4 to 2 bytes to avoid nmethod's header size increase.
> 
> Tested tier1-5, stress,xcomp
> 
> Our performance testing does not show difference.
> 
> Example of updated `-XX:+PrintNMethodStatistics` output is in JBS comment.

src/hotspot/share/code/nmethod.hpp line 476:

> 474:     passed,
> 475:     code_cache_full,
> 476:     out_of_memory

Maybe `out_of_c_heap_memory` would be clearer? Or `out_of_immutable_data_memory` if immutable data may not always be malloc'ed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18984#discussion_r1581904919

From dnsimon at openjdk.org  Sat Apr 27 21:00:05 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Sat, 27 Apr 2024 21:00:05 GMT
Subject: RFR: 8331087: Move immutable nmethod data from CodeCache
In-Reply-To: <ineXbCWnnv5cRobzHW2TZVCIq8wuV8pPZ1PEn7-5yGg=.ba55a4e9-ced5-473f-8801-05e2d4efc495@github.com>
References: <ineXbCWnnv5cRobzHW2TZVCIq8wuV8pPZ1PEn7-5yGg=.ba55a4e9-ced5-473f-8801-05e2d4efc495@github.com>
Message-ID: <-EcNmtS6moX1Bx6ZDQfe46MtUGvk-qEiLTeX0O5qOyE=.2c839c6a-dc79-4851-8b32-230bfc66661f@github.com>

On Fri, 26 Apr 2024 21:16:03 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Move immutable nmethod's data from CodeCache to C heap. It includes `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data, speculations, jvmci_data`. It amounts for about 30% (optimized VM) of space in CodeCache.
> 
> Use HotSpot's `os::malloc()` to allocate memory in C heap for immutable nmethod's data. Bail out compilation if allocation failed.
> 
> Shuffle fields order and change some fields size from 4 to 2 bytes to avoid nmethod's header size increase.
> 
> Tested tier1-5, stress,xcomp
> 
> Our performance testing does not show difference.
> 
> Example of updated `-XX:+PrintNMethodStatistics` output is in JBS comment.

src/hotspot/share/jvmci/jvmciRuntime.cpp line 2178:

> 2176:                                                         nmethod_mirror_name,
> 2177:                                                         failed_speculations);
> 2178:       nmethod::ResultStatus result_status;

Please propagate the new `out_of_memory` result throughout JVMCI (e.g. in `JVMCI::CodeInstallResult` enum and `HotSpotVMConfig.getCodeInstallResultDescription` method).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18984#discussion_r1581906300

From kvn at openjdk.org  Sun Apr 28 02:28:10 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sun, 28 Apr 2024 02:28:10 GMT
Subject: RFR: 8331087: Move immutable nmethod data from CodeCache
In-Reply-To: <BTVobrnBD1mUXws4QI_rtbups-orMbBBSnRfCNvTm-Y=.fde9f3b3-63ce-474c-9861-9628664cba05@github.com>
References: <ineXbCWnnv5cRobzHW2TZVCIq8wuV8pPZ1PEn7-5yGg=.ba55a4e9-ced5-473f-8801-05e2d4efc495@github.com>
 <BTVobrnBD1mUXws4QI_rtbups-orMbBBSnRfCNvTm-Y=.fde9f3b3-63ce-474c-9861-9628664cba05@github.com>
Message-ID: <Q9GEVVJRJbiT5aHSDpaw_BynkcoEo-2FcjsrVzUxz_0=.b70ca115-f79e-4ecd-8d50-f50237dc431d@github.com>

On Sat, 27 Apr 2024 20:48:38 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Move immutable nmethod's data from CodeCache to C heap. It includes `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data, speculations, jvmci_data`. It amounts for about 30% (optimized VM) of space in CodeCache.
>> 
>> Use HotSpot's `os::malloc()` to allocate memory in C heap for immutable nmethod's data. Bail out compilation if allocation failed.
>> 
>> Shuffle fields order and change some fields size from 4 to 2 bytes to avoid nmethod's header size increase.
>> 
>> Tested tier1-5, stress,xcomp
>> 
>> Our performance testing does not show difference.
>> 
>> Example of updated `-XX:+PrintNMethodStatistics` output is in JBS comment.
>
> src/hotspot/share/code/nmethod.hpp line 476:
> 
>> 474:     passed,
>> 475:     code_cache_full,
>> 476:     out_of_memory
> 
> Maybe `out_of_c_heap_memory` would be clearer? Or `out_of_immutable_data_memory` if immutable data may not always be malloc'ed.

May be `no_space_for_immutable_data`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18984#discussion_r1581998799

From kvn at openjdk.org  Sun Apr 28 02:36:09 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sun, 28 Apr 2024 02:36:09 GMT
Subject: RFR: 8331087: Move immutable nmethod data from CodeCache
In-Reply-To: <ineXbCWnnv5cRobzHW2TZVCIq8wuV8pPZ1PEn7-5yGg=.ba55a4e9-ced5-473f-8801-05e2d4efc495@github.com>
References: <ineXbCWnnv5cRobzHW2TZVCIq8wuV8pPZ1PEn7-5yGg=.ba55a4e9-ced5-473f-8801-05e2d4efc495@github.com>
Message-ID: <6wgRfo3fvRqgQGGZ-j_NzKm0g8KGFxqC8ZLB1-IHPsw=.b7edb4ff-e87c-48cf-b8c9-f7753f586f9f@github.com>

On Fri, 26 Apr 2024 21:16:03 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Move immutable nmethod's data from CodeCache to C heap. It includes `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data, speculations, jvmci_data`. It amounts for about 30% (optimized VM) of space in CodeCache.
> 
> Use HotSpot's `os::malloc()` to allocate memory in C heap for immutable nmethod's data. Bail out compilation if allocation failed.
> 
> Shuffle fields order and change some fields size from 4 to 2 bytes to avoid nmethod's header size increase.
> 
> Tested tier1-5, stress,xcomp
> 
> Our performance testing does not show difference.
> 
> Example of updated `-XX:+PrintNMethodStatistics` output is in JBS comment.

@dean-long and @dougxc  

I am thinking may be I should not bailout  when `malloc` (or other space reservation in a future) failed to allocate memory for immutable data. But instead increase nmethod size and put immutable data there (as before).  Then we bailout only when CodeCache is full as before and we don't need `out_of_memory` failure reason. May be only record that in logs (when they are enabled).

What do you think?

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

PR Comment: https://git.openjdk.org/jdk/pull/18984#issuecomment-2081297482

From dlong at openjdk.org  Sun Apr 28 07:05:05 2024
From: dlong at openjdk.org (Dean Long)
Date: Sun, 28 Apr 2024 07:05:05 GMT
Subject: RFR: 8331087: Move immutable nmethod data from CodeCache
In-Reply-To: <ineXbCWnnv5cRobzHW2TZVCIq8wuV8pPZ1PEn7-5yGg=.ba55a4e9-ced5-473f-8801-05e2d4efc495@github.com>
References: <ineXbCWnnv5cRobzHW2TZVCIq8wuV8pPZ1PEn7-5yGg=.ba55a4e9-ced5-473f-8801-05e2d4efc495@github.com>
Message-ID: <O-VmFLGCDRJbau_fTVlYywDvIyabqSviaLjCSOqacl8=.0ce533d5-56bf-4a34-8877-2531bb16dd45@github.com>

On Fri, 26 Apr 2024 21:16:03 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Move immutable nmethod's data from CodeCache to C heap. It includes `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data, speculations, jvmci_data`. It amounts for about 30% (optimized VM) of space in CodeCache.
> 
> Use HotSpot's `os::malloc()` to allocate memory in C heap for immutable nmethod's data. Bail out compilation if allocation failed.
> 
> Shuffle fields order and change some fields size from 4 to 2 bytes to avoid nmethod's header size increase.
> 
> Tested tier1-5, stress,xcomp
> 
> Our performance testing does not show difference.
> 
> Example of updated `-XX:+PrintNMethodStatistics` output is in JBS comment.

It only makes sense if the immutable data heap is not also used for other critical resources.  If malloc or metaspace were used as the immutable data heap, normally failures in those heaps are fatal, because other critical resources (monitors, classes, etc) are allocated from there, so any failure means the JVM is about to die.  There's no reason to find a fall-back method to allocate a new nmethod in that case.

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

PR Comment: https://git.openjdk.org/jdk/pull/18984#issuecomment-2081364009

From dnsimon at openjdk.org  Sun Apr 28 10:35:05 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Sun, 28 Apr 2024 10:35:05 GMT
Subject: RFR: 8331087: Move immutable nmethod data from CodeCache
In-Reply-To: <O-VmFLGCDRJbau_fTVlYywDvIyabqSviaLjCSOqacl8=.0ce533d5-56bf-4a34-8877-2531bb16dd45@github.com>
References: <ineXbCWnnv5cRobzHW2TZVCIq8wuV8pPZ1PEn7-5yGg=.ba55a4e9-ced5-473f-8801-05e2d4efc495@github.com>
 <O-VmFLGCDRJbau_fTVlYywDvIyabqSviaLjCSOqacl8=.0ce533d5-56bf-4a34-8877-2531bb16dd45@github.com>
Message-ID: <VNg1NAp73ux7o19Z6kYpTatCZ4clsFkKDwlsY6d7pGQ=.acb121df-d29b-4b4d-8f1c-8dabe478004d@github.com>

On Sun, 28 Apr 2024 07:02:40 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Move immutable nmethod's data from CodeCache to C heap. It includes `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data, speculations, jvmci_data`. It amounts for about 30% (optimized VM) of space in CodeCache.
>> 
>> Use HotSpot's `os::malloc()` to allocate memory in C heap for immutable nmethod's data. Bail out compilation if allocation failed.
>> 
>> Shuffle fields order and change some fields size from 4 to 2 bytes to avoid nmethod's header size increase.
>> 
>> Tested tier1-5, stress,xcomp
>> 
>> Our performance testing does not show difference.
>> 
>> Example of updated `-XX:+PrintNMethodStatistics` output is in JBS comment.
>
> It only makes sense if the immutable data heap is not also used for other critical resources.  If malloc or metaspace were used as the immutable data heap, normally failures in those heaps are fatal, because other critical resources (monitors, classes, etc) are allocated from there, so any failure means the JVM is about to die.  There's no reason to find a fall-back method to allocate a new nmethod in that case.

Just to be clear @dean-long , you're saying failure to allocate immutable data in the C heap should result in a fatal error? Makes sense to me as the VM must indeed be very close to crashing anyway in that case. It also, obviates the need for propagating `out_of_memory_error` to JVMCI code.

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

PR Comment: https://git.openjdk.org/jdk/pull/18984#issuecomment-2081427477

From sebastian.lovdahl at hibox.tv  Sun Apr 28 19:33:06 2024
From: sebastian.lovdahl at hibox.tv (=?UTF-8?Q?Sebastian_L=C3=B6vdahl?=)
Date: Sun, 28 Apr 2024 22:33:06 +0300
Subject: 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid
 (Kubernetes debug container)
Message-ID: <a0c354b0-87ad-4526-a77f-18b0c33989ed@hibox.tv>

Hi all,

It seems like my fix for https://bugs.openjdk.org/browse/JDK-8226919 
regressed one use-case for Kubernetes debug containers (and other 
technically similar approaches). Quoting @jdoylei from 
https://github.com/openjdk/jdk/pull/17628#issuecomment-1969769654:

"We're running jcmd (OpenJDK build 17.0.10+7-LTS) and the target JVM in 
two separate containers in a Kubernetes pod. The target JVM container is 
already running, and then we use kubectl debug --target=... to start a 
Kubernetes debug container with jcmd that targets the first container. 
Given the --target option, they share the same Linux process namespace 
(both think the target JVM is PID 1). But since they are separate 
containers, they see different root filesystems (jcmd container sees the 
target JVM tmpdir under /proc/1/root/tmp but has its own distinct /tmp 
directory)."

I think I can confirm that there is a regression. Using a locally built 
JDK from master as of 2024-04-28 
(16c7dcdb04a7c220684a20eb4a0da4505ae03813), but using raw Docker 
containers instead of Kubernetes + kubectl debug:


slovdahl at ubuntu2204:~/reproducer$ cat Reproducer.java
import java.io.IOException;
import java.net.InetSocketAddress;
import java.net.ServerSocket;

public class Reproducer {
 ? public static void main(String[] args) throws InterruptedException, 
IOException {
 ??? System.out.println("Hello, World!");
 ??? try (var server = new ServerSocket()) {
 ????? server.bind(new InetSocketAddress("localhost", 81));
 ????? System.out.println("Bound to port 81");
 ????? while (true) {
 ??????? Thread.sleep(1_000L);
 ????? }
 ??? }
 ? }
}

slovdahl at ubuntu2204:~/reproducer$ docker run --interactive --tty --rm 
--name app-container --volume 
~/jdk/build/linux-x86_64-server-release/images/jdk/:/jdk --volume .:/app 
--workdir /app ubuntu:22.04 /bin/bash
root at d1f87b8059ea:/app# /jdk/bin/java -version
openjdk version "23-internal" 2024-09-17
OpenJDK Runtime Environment (build 23-internal-adhoc.slovdahl.jdk)
OpenJDK 64-Bit Server VM (build 23-internal-adhoc.slovdahl.jdk, mixed 
mode, sharing)

root at d1f87b8059ea:/app# /jdk/bin/java Reproducer.java
Hello, World!
Bound to port 81


Locally built JDK and jcmd from the host (works):

slovdahl at ubuntu2204:~/reproducer$ sudo 
~/jdk/build/linux-x86_64-server-release/images/jdk/bin/jcmd 942781 
VM.version
942781:
OpenJDK 64-Bit Server VM version 23-internal-adhoc.slovdahl.jdk
JDK 23.0.0

jcmd from a sidecar Docker container mounted into the same process 
namespace (does NOT work, regressed):

slovdahl at ubuntu2204:~/reproducer$ docker run --interactive --tty --rm 
--pid=container:app-container --volume 
~/jdk/build/linux-x86_64-server-release/images/jdk/:/jdk ubuntu:22.04 
/bin/bash
root at 27d8be9186b7:/# /jdk/bin/jcmd
26 jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher Reproducer.java
59 jdk.jcmd/sun.tools.jcmd.JCmd
root at 27d8be9186b7:/# /jdk/bin/jcmd 26 VM.version
26:
com.sun.tools.attach.AttachNotSupportedException: Unable to open socket 
file /tmp/.java_pid26: target process 26 doesn't respond within 10500ms 
or HotSpot VM not loaded
 ??? at 
jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:99)
 ??? at 
jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58)
 ??? at 
jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207)
 ??? at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
 ??? at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)


Using Temurin 17.0.11 from the host (works):

slovdahl at ubuntu2204:~/reproducer$ 
/usr/lib/jvm/temurin-17-jdk-amd64/bin/java -version
openjdk version "17.0.11" 2024-04-16
OpenJDK Runtime Environment Temurin-17.0.11+9 (build 17.0.11+9)
OpenJDK 64-Bit Server VM Temurin-17.0.11+9 (build 17.0.11+9, mixed mode, 
sharing)
slovdahl at ubuntu2204:~/reproducer$ sudo 
/usr/lib/jvm/temurin-17-jdk-amd64/bin/jcmd 942781 VM.version
942781:
OpenJDK 64-Bit Server VM version 23-internal-adhoc.slovdahl.jdk
JDK 23.0.0


Temurin 17.0.11 jcmd from a sidecar Docker container mounted into the 
same process namespace (works):

slovdahl at ubuntu2204:~/reproducer$ docker run --interactive --tty --rm 
--pid=container:app-container eclipse-temurin:17.0.11_9-jdk-jammy /bin/bash
root at fcbd6e4be9eb:/# java -version
openjdk version "17.0.11" 2024-04-16
OpenJDK Runtime Environment Temurin-17.0.11+9 (build 17.0.11+9)
OpenJDK 64-Bit Server VM Temurin-17.0.11+9 (build 17.0.11+9, mixed mode, 
sharing)
root at fcbd6e4be9eb:/# jcmd
138 jdk.jcmd/sun.tools.jcmd.JCmd
26 jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher Reproducer.java
root at fcbd6e4be9eb:/# jcmd 26 VM.version
26:
OpenJDK 64-Bit Server VM version 23-internal-adhoc.slovdahl.jdk
JDK 23.0.0


Curiously enough, there is a test that on the surface seemed to be 
written specifically for this case 
(test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java). But the 
devil is in the details: in TestJcmdWithSideCar /tmp in the main 
container is a volume that is mounted into the sidecar container, so 
attaching from the sidecar works without going through /proc/<pid>/cwd, 
and hence it works both before and after my fix.

Knowing up front that /tmp needs to be a volume and that it needs to be 
mounted into the sidecar container feels like a hard ask to me, so I can 
definitely see why one would like to have the possibility to attach to 
containers without having to do that. So, I think it would make sense to 
get this regression fixed. Maybe also change the existing test to not 
mount /tmp between the containers? Or as an alternative, have tests for 
both the "mount /tmp" approach and for not doing it.

Thoughts about this? I could try to give it a look if you think it makes 
sense.

Best regards,

-- 
Sebastian L?vdahl
Senior Software Engineer, Hibox Systems - https://www.hibox.tv
sebastian.lovdahl at hibox.tv


From duke at openjdk.org  Sun Apr 28 19:37:17 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Sun, 28 Apr 2024 19:37:17 GMT
Subject: RFR: 8226919: attach in linux hangs due to permission denied
 accessing /proc/pid/root
In-Reply-To: <Zes91i-g8se0PkACelUnPKZAmWrQoRE_unPWK9M84Ck=.629874af-b415-4009-83d2-c74db89930e7@github.com>
References: <yH8KKw_lhN7hHYsK39QN290BXDYQm1I4LNoHSfRZjhk=.791bcae7-422e-4913-9f99-ba32d2b3f24b@github.com>
 <7vessvLp3h1VbXvYrU855MWBnK6MB0XLsQokmm6ynM4=.e97f68cc-efd7-4c83-a36f-4031d784e5b1@github.com>
 <2ofyu9f8afgL3MxQ4YeMk9Bk6p-a55rMOXlHq3Q41ZY=.d6d2606a-3a95-479e-8f0b-7ca87cf83575@github.com>
 <Xld_4AoPH_tTfYzwfe2sqSDlZVN4aylJ9rli9dMqVWw=.42ea36fb-7b77-4e59-936a-357d82eb4dcf@github.com>
 <Tnxg3PZLqM5MbwNpIZQp5eYSJfzJAwdmb7lJfy7BSKA=.4c997ccb-37e1-453e-8911-07f71c5574cb@github.com>
 <RoRpyedryq8wYcfZG-xLQI1vRfuL9NIvAFuVF5jIZ7w=.f9dcc4b6-55bc-4303-828c-bbe468b664ef@github.com>
 <Zes91i-g8se0PkACelUnPKZAmWrQoRE_unPWK9M84Ck=.629874af-b415-4009-83d2-c74db89930e7@github.com>
Message-ID: <-h0EE20B_qMzfT6X1yeSIBFn-auM6ktxiytxzhqcCwU=.c6c9815b-3159-480e-92ae-48ba53e037b4@github.com>

On Fri, 1 Mar 2024 15:22:51 GMT, jdoylei <duke at openjdk.org> wrote:

>> Logged https://bugs.openjdk.org/browse/JDK-8327114 for investigation.  Thanks @jdoylei  !
>
> @kevinjwalls - Perfect, thank you for opening the JBS bug!

Thanks for the detailed write-up, @jdoylei! I'm sorry to have introduced a regression here. Good that the backporting was held off a bit at least :) Let's continue the discussion at https://mail.openjdk.org/pipermail/serviceability-dev/2024-April/055317.html.

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

PR Comment: https://git.openjdk.org/jdk/pull/17628#issuecomment-2081618227

From kvn at openjdk.org  Sun Apr 28 23:37:22 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sun, 28 Apr 2024 23:37:22 GMT
Subject: RFR: 8331087: Move immutable nmethod data from CodeCache [v2]
In-Reply-To: <ineXbCWnnv5cRobzHW2TZVCIq8wuV8pPZ1PEn7-5yGg=.ba55a4e9-ced5-473f-8801-05e2d4efc495@github.com>
References: <ineXbCWnnv5cRobzHW2TZVCIq8wuV8pPZ1PEn7-5yGg=.ba55a4e9-ced5-473f-8801-05e2d4efc495@github.com>
Message-ID: <J_FTlr1pslzpbCB5PVAL1nHycdMGO5O6JzDYcH3zTaU=.e77a52e4-4784-40b1-afaf-1a17cb5d760f@github.com>

> Move immutable nmethod's data from CodeCache to C heap. It includes `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data, speculations, jvmci_data`. It amounts for about 30% (optimized VM) of space in CodeCache.
> 
> Use HotSpot's `os::malloc()` to allocate memory in C heap for immutable nmethod's data. Bail out compilation if allocation failed.
> 
> Shuffle fields order and change some fields size from 4 to 2 bytes to avoid nmethod's header size increase.
> 
> Tested tier1-5, stress,xcomp
> 
> Our performance testing does not show difference.
> 
> Example of updated `-XX:+PrintNMethodStatistics` output is in JBS comment.

Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:

  Address comments. Moved jvmci_data back to mutable data section.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18984/files
  - new: https://git.openjdk.org/jdk/pull/18984/files/6b1f69d9..1824f46c

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

  Stats: 98 lines in 5 files changed: 39 ins; 36 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/18984.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18984/head:pull/18984

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

From kvn at openjdk.org  Sun Apr 28 23:45:08 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sun, 28 Apr 2024 23:45:08 GMT
Subject: RFR: 8331087: Move immutable nmethod data from CodeCache [v2]
In-Reply-To: <J_FTlr1pslzpbCB5PVAL1nHycdMGO5O6JzDYcH3zTaU=.e77a52e4-4784-40b1-afaf-1a17cb5d760f@github.com>
References: <ineXbCWnnv5cRobzHW2TZVCIq8wuV8pPZ1PEn7-5yGg=.ba55a4e9-ced5-473f-8801-05e2d4efc495@github.com>
 <J_FTlr1pslzpbCB5PVAL1nHycdMGO5O6JzDYcH3zTaU=.e77a52e4-4784-40b1-afaf-1a17cb5d760f@github.com>
Message-ID: <yRtgzwTf8Q3Px7ePn93BvritGR7FEn5Yz9V67sBIpaI=.5a2d0908-262b-4b62-9526-c8a5988f7dc3@github.com>

On Sun, 28 Apr 2024 23:37:22 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Move immutable nmethod's data from CodeCache to C heap. It includes `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data, speculations, jvmci_data`. It amounts for about 30% (optimized VM) of space in CodeCache.
>> 
>> Use HotSpot's `os::malloc()` to allocate memory in C heap for immutable nmethod's data. Bail out compilation if allocation failed.
>> 
>> Shuffle fields order and change some fields size from 4 to 2 bytes to avoid nmethod's header size increase.
>> 
>> Tested tier1-5, stress,xcomp
>> 
>> Our performance testing does not show difference.
>> 
>> Example of updated `-XX:+PrintNMethodStatistics` output is in JBS comment.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments. Moved jvmci_data back to mutable data section.

Update:
1. Addressed @dean-long first comments.
2. Based on discussion with Doug and Tom (see comments in [JDK-8331087](https://bugs.openjdk.org/browse/JDK-8331087)), moved `jvmci_data` back to nmethod's mutable data section.
3. Replaced my allocation failure handling code with call to `vm_exit_out_of_memory()`.

    I verified (with `UseNewCode` hack`) that out of memory is correctly reported in fastdebug and product VMs:

#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (malloc) failed to allocate 64 bytes. Error detail: nmethod: no space for immutable data
# An error report file with more information is saved as:
# /scratch/kvn/jdk_git/hs_err_pid4086275.log

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

PR Comment: https://git.openjdk.org/jdk/pull/18984#issuecomment-2081701059

From thartmann at openjdk.org  Mon Apr 29 06:36:04 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 29 Apr 2024 06:36:04 GMT
Subject: RFR: 8331087: Move immutable nmethod data from CodeCache [v2]
In-Reply-To: <J_FTlr1pslzpbCB5PVAL1nHycdMGO5O6JzDYcH3zTaU=.e77a52e4-4784-40b1-afaf-1a17cb5d760f@github.com>
References: <ineXbCWnnv5cRobzHW2TZVCIq8wuV8pPZ1PEn7-5yGg=.ba55a4e9-ced5-473f-8801-05e2d4efc495@github.com>
 <J_FTlr1pslzpbCB5PVAL1nHycdMGO5O6JzDYcH3zTaU=.e77a52e4-4784-40b1-afaf-1a17cb5d760f@github.com>
Message-ID: <aSZuAnsXDPTx8Bvs7dCdAfVR8dqcyRRuz6KnlsHCHj8=.09947c7f-bdbe-4a97-81be-63fe0be27af7@github.com>

On Sun, 28 Apr 2024 23:37:22 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Move immutable nmethod's data from CodeCache to C heap. It includes `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data, speculations`. It amounts for about 30% (optimized VM) of space in CodeCache.
>> 
>> Use HotSpot's `os::malloc()` to allocate memory in C heap for immutable nmethod's data. Call `vm_exit_out_of_memory()` if allocation failed.
>> 
>> Shuffle fields order and change some fields size from 4 to 2 bytes to avoid nmethod's header size increase.
>> 
>> Tested tier1-5, stress,xcomp
>> 
>> Our performance testing does not show difference.
>> 
>> Example of updated `-XX:+PrintNMethodStatistics` output is in JBS comment.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments. Moved jvmci_data back to mutable data section.

Looks good to me. Did you measure any impact on performance (potentially due to improved code density)?

What's left for [JDK-7072317](https://bugs.openjdk.org/browse/JDK-7072317)?

I wonder if the `CHECKED_CAST` changes shouldn't go into a separate RFE.

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

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18984#pullrequestreview-2027660174

From dlong at openjdk.org  Mon Apr 29 07:51:09 2024
From: dlong at openjdk.org (Dean Long)
Date: Mon, 29 Apr 2024 07:51:09 GMT
Subject: RFR: 8331087: Move immutable nmethod data from CodeCache
In-Reply-To: <O-VmFLGCDRJbau_fTVlYywDvIyabqSviaLjCSOqacl8=.0ce533d5-56bf-4a34-8877-2531bb16dd45@github.com>
References: <ineXbCWnnv5cRobzHW2TZVCIq8wuV8pPZ1PEn7-5yGg=.ba55a4e9-ced5-473f-8801-05e2d4efc495@github.com>
 <O-VmFLGCDRJbau_fTVlYywDvIyabqSviaLjCSOqacl8=.0ce533d5-56bf-4a34-8877-2531bb16dd45@github.com>
Message-ID: <Jvt_ge0xhHRYw0g3aQ0h0clh6uJ90K8AdXuY3wJDOE0=.825fff6f-1f06-43a0-bc97-47c8fad77c49@github.com>

On Sun, 28 Apr 2024 07:02:40 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Move immutable nmethod's data from CodeCache to C heap. It includes `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data, speculations`. It amounts for about 30% (optimized VM) of space in CodeCache.
>> 
>> Use HotSpot's `os::malloc()` to allocate memory in C heap for immutable nmethod's data. Call `vm_exit_out_of_memory()` if allocation failed.
>> 
>> Shuffle fields order and change some fields size from 4 to 2 bytes to avoid nmethod's header size increase.
>> 
>> Tested tier1-5, stress,xcomp
>> 
>> Our performance testing does not show difference.
>> 
>> Example of updated `-XX:+PrintNMethodStatistics` output is in JBS comment.
>
> It only makes sense if the immutable data heap is not also used for other critical resources.  If malloc or metaspace were used as the immutable data heap, normally failures in those heaps are fatal, because other critical resources (monitors, classes, etc) are allocated from there, so any failure means the JVM is about to die.  There's no reason to find a fall-back method to allocate a new nmethod in that case.

> Just to be clear @dean-long , you're saying failure to allocate immutable data in the C heap should result in a fatal error? Makes sense to me as the VM must indeed be very close to crashing anyway in that case. It also, obviates the need for propagating `out_of_memory_error` to JVMCI code.

I hadn't thought it through that far, actually.  I was only pointing out that the proposed fall-back:

> increase nmethod size and put immutable data there (as before).

isn't worth the trouble.  But making the C heap failure fatal immediately is reasonable, especially if it simplifies JVMCI error reporting.

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

PR Comment: https://git.openjdk.org/jdk/pull/18984#issuecomment-2082083104

From dlong at openjdk.org  Mon Apr 29 07:59:06 2024
From: dlong at openjdk.org (Dean Long)
Date: Mon, 29 Apr 2024 07:59:06 GMT
Subject: RFR: 8331087: Move immutable nmethod data from CodeCache [v2]
In-Reply-To: <J_FTlr1pslzpbCB5PVAL1nHycdMGO5O6JzDYcH3zTaU=.e77a52e4-4784-40b1-afaf-1a17cb5d760f@github.com>
References: <ineXbCWnnv5cRobzHW2TZVCIq8wuV8pPZ1PEn7-5yGg=.ba55a4e9-ced5-473f-8801-05e2d4efc495@github.com>
 <J_FTlr1pslzpbCB5PVAL1nHycdMGO5O6JzDYcH3zTaU=.e77a52e4-4784-40b1-afaf-1a17cb5d760f@github.com>
Message-ID: <lRVuxpbQtV-iZPlcCP3UXiB-wDXDGcOdSrc414dUNC4=.a677843e-6803-4d71-bcf8-e1233a572a6c@github.com>

On Sun, 28 Apr 2024 23:37:22 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Move immutable nmethod's data from CodeCache to C heap. It includes `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data, speculations`. It amounts for about 30% (optimized VM) of space in CodeCache.
>> 
>> Use HotSpot's `os::malloc()` to allocate memory in C heap for immutable nmethod's data. Call `vm_exit_out_of_memory()` if allocation failed.
>> 
>> Shuffle fields order and change some fields size from 4 to 2 bytes to avoid nmethod's header size increase.
>> 
>> Tested tier1-5, stress,xcomp
>> 
>> Our performance testing does not show difference.
>> 
>> Example of updated `-XX:+PrintNMethodStatistics` output is in JBS comment.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments. Moved jvmci_data back to mutable data section.

Marked as reviewed by dlong (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18984#pullrequestreview-2027786061

From tschatzl at openjdk.org  Mon Apr 29 08:17:10 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 29 Apr 2024 08:17:10 GMT
Subject: RFR: 8330694: Rename 'HeapRegion' to 'G1HeapRegion' [v4]
In-Reply-To: <tKoc_1Z7ZAN6YuR_BpkrbOMi54UoDk0WYeHHK5aE3XE=.0ca685db-af09-4885-89ee-e35b0e9cf2b8@github.com>
References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
 <tKoc_1Z7ZAN6YuR_BpkrbOMi54UoDk0WYeHHK5aE3XE=.0ca685db-af09-4885-89ee-e35b0e9cf2b8@github.com>
Message-ID: <xZ9uTLfJfGyvsoRO1Y32NoV-NuGpJ-3C3J0voQCcNEA=.65cada0e-b01f-4789-b82d-b18b1415d942@github.com>

On Sat, 27 Apr 2024 02:34:21 GMT, Lei Zaakjyu <duke at openjdk.org> wrote:

>> follow up 8267941
>
> Lei Zaakjyu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix indentation

mach5 higher tier SA tests are fine.
What are your plans for the remaining SA renames (would highly recommend to add) and the G1HeapRegion related helper classes?

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

PR Comment: https://git.openjdk.org/jdk/pull/18871#issuecomment-2082124530

From dnsimon at openjdk.org  Mon Apr 29 08:53:05 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 29 Apr 2024 08:53:05 GMT
Subject: RFR: 8331087: Move immutable nmethod data from CodeCache [v2]
In-Reply-To: <J_FTlr1pslzpbCB5PVAL1nHycdMGO5O6JzDYcH3zTaU=.e77a52e4-4784-40b1-afaf-1a17cb5d760f@github.com>
References: <ineXbCWnnv5cRobzHW2TZVCIq8wuV8pPZ1PEn7-5yGg=.ba55a4e9-ced5-473f-8801-05e2d4efc495@github.com>
 <J_FTlr1pslzpbCB5PVAL1nHycdMGO5O6JzDYcH3zTaU=.e77a52e4-4784-40b1-afaf-1a17cb5d760f@github.com>
Message-ID: <2DurRx2sxaKxnkJTKVqsFU4jL6Crc05p8HPnFVPvDPw=.71bff5c9-9a40-4898-a83e-ee2dc769fb51@github.com>

On Sun, 28 Apr 2024 23:37:22 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Move immutable nmethod's data from CodeCache to C heap. It includes `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data, speculations`. It amounts for about 30% (optimized VM) of space in CodeCache.
>> 
>> Use HotSpot's `os::malloc()` to allocate memory in C heap for immutable nmethod's data. Call `vm_exit_out_of_memory()` if allocation failed.
>> 
>> Shuffle fields order and change some fields size from 4 to 2 bytes to avoid nmethod's header size increase.
>> 
>> Tested tier1-5, stress,xcomp
>> 
>> Our performance testing does not show difference.
>> 
>> Example of updated `-XX:+PrintNMethodStatistics` output is in JBS comment.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments. Moved jvmci_data back to mutable data section.

Marked as reviewed by dnsimon (Reviewer).

JVMCI changes now look good to me.

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

PR Review: https://git.openjdk.org/jdk/pull/18984#pullrequestreview-2027884309
PR Comment: https://git.openjdk.org/jdk/pull/18984#issuecomment-2082185011

From dnsimon at openjdk.org  Mon Apr 29 12:32:07 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 29 Apr 2024 12:32:07 GMT
Subject: RFR: 8318682: SA decoding of scalar replaced objects is broken
 [v6]
In-Reply-To: <3vUQFrFjSw6SBZMlDqrUNW0-e37Ocj3hoGPU5qXE-EQ=.32395005-fc6c-486a-b384-78bbeac409b2@github.com>
References: <R64I76cjq_B8227oAI3C_B62NQSa3-HVn13a6Fj0alo=.28a782c9-d03c-4126-9aab-6e6134b0dbe1@github.com>
 <3vUQFrFjSw6SBZMlDqrUNW0-e37Ocj3hoGPU5qXE-EQ=.32395005-fc6c-486a-b384-78bbeac409b2@github.com>
Message-ID: <r-UG4JlyM4ZdA8shw8pIT7qz9LV1WicCKZu_JVWiPiM=.de496035-299e-4dad-b783-afddfd8bf549@github.com>

On Wed, 17 Jan 2024 19:52:32 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> The changes for JDK-8287061 didn't update the SA decoding logic and there are other places where the decoding has gotten out of sync with HotSpot.  Some of them can't be tested because they are part of JVMCI but I've added a directed test for the JDK-8287061 code and a more brute force test that tries to decode everything.
>
> Tom Rodriguez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Let's merge this soon Tom.

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

PR Comment: https://git.openjdk.org/jdk/pull/17407#issuecomment-2082605948

From kvn at openjdk.org  Mon Apr 29 14:54:06 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 29 Apr 2024 14:54:06 GMT
Subject: RFR: 8331087: Move immutable nmethod data from CodeCache [v2]
In-Reply-To: <aSZuAnsXDPTx8Bvs7dCdAfVR8dqcyRRuz6KnlsHCHj8=.09947c7f-bdbe-4a97-81be-63fe0be27af7@github.com>
References: <ineXbCWnnv5cRobzHW2TZVCIq8wuV8pPZ1PEn7-5yGg=.ba55a4e9-ced5-473f-8801-05e2d4efc495@github.com>
 <J_FTlr1pslzpbCB5PVAL1nHycdMGO5O6JzDYcH3zTaU=.e77a52e4-4784-40b1-afaf-1a17cb5d760f@github.com>
 <aSZuAnsXDPTx8Bvs7dCdAfVR8dqcyRRuz6KnlsHCHj8=.09947c7f-bdbe-4a97-81be-63fe0be27af7@github.com>
Message-ID: <uaCDAc18AkJi_sAtf1FqF-5UEZ0KvurgHnBcEUKR-4c=.a91a2512-9f95-4c67-a39e-f4af6c74a4d6@github.com>

On Mon, 29 Apr 2024 06:33:09 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Looks good to me. Did you measure any impact on performance (potentially due to improved code density)?

Thank you, @TobiHartmann, for review.

> What's left for [JDK-7072317](https://bugs.openjdk.org/browse/JDK-7072317)?

Make Relocation info (10% of nmethod size) immutable by moving all encoded pointers (external words and others, which we need to patch in Leyden when loading cached code) from it into separate mutable section.
 
> I wonder if the `CHECKED_CAST` changes shouldn't go into a separate RFE.

No, I want clear information which cast failed instead of trying to reproduce very intermittent failure like this: [JDK-8331253](https://bugs.openjdk.org/browse/JDK-8331253). When you have several `checked_cast<T>` in one method it is impossible to find which failed without this macro.

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

PR Comment: https://git.openjdk.org/jdk/pull/18984#issuecomment-2082953366

From kvn at openjdk.org  Mon Apr 29 16:02:17 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 29 Apr 2024 16:02:17 GMT
Subject: RFR: 8331087: Move immutable nmethod data from CodeCache [v2]
In-Reply-To: <J_FTlr1pslzpbCB5PVAL1nHycdMGO5O6JzDYcH3zTaU=.e77a52e4-4784-40b1-afaf-1a17cb5d760f@github.com>
References: <ineXbCWnnv5cRobzHW2TZVCIq8wuV8pPZ1PEn7-5yGg=.ba55a4e9-ced5-473f-8801-05e2d4efc495@github.com>
 <J_FTlr1pslzpbCB5PVAL1nHycdMGO5O6JzDYcH3zTaU=.e77a52e4-4784-40b1-afaf-1a17cb5d760f@github.com>
Message-ID: <Hoe1uvsY0XpRK8tUgukGLjUS0GtbZ8cUcXS55O_C4xg=.11763c09-9b1c-49e9-8200-a4eeed5f1b84@github.com>

On Sun, 28 Apr 2024 23:37:22 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Move immutable nmethod's data from CodeCache to C heap. It includes `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data, speculations`. It amounts for about 30% (optimized VM) of space in CodeCache.
>> 
>> Use HotSpot's `os::malloc()` to allocate memory in C heap for immutable nmethod's data. Call `vm_exit_out_of_memory()` if allocation failed.
>> 
>> Shuffle fields order and change some fields size from 4 to 2 bytes to avoid nmethod's header size increase.
>> 
>> Tested tier1-5, stress,xcomp
>> 
>> Our performance testing does not show difference.
>> 
>> Example of updated `-XX:+PrintNMethodStatistics` output is in JBS comment.
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments. Moved jvmci_data back to mutable data section.

Thank you, Dean, Doug and Tobias for reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/18984#issuecomment-2083102730

From kvn at openjdk.org  Mon Apr 29 16:02:17 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 29 Apr 2024 16:02:17 GMT
Subject: Integrated: 8331087: Move immutable nmethod data from CodeCache
In-Reply-To: <ineXbCWnnv5cRobzHW2TZVCIq8wuV8pPZ1PEn7-5yGg=.ba55a4e9-ced5-473f-8801-05e2d4efc495@github.com>
References: <ineXbCWnnv5cRobzHW2TZVCIq8wuV8pPZ1PEn7-5yGg=.ba55a4e9-ced5-473f-8801-05e2d4efc495@github.com>
Message-ID: <L7Ie2phaKSEk-FxaOc4XYTy_q5yyPRGONvg2FqC0hrg=.df742515-d231-4521-81ba-04d3ead6fadb@github.com>

On Fri, 26 Apr 2024 21:16:03 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Move immutable nmethod's data from CodeCache to C heap. It includes `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data, speculations`. It amounts for about 30% (optimized VM) of space in CodeCache.
> 
> Use HotSpot's `os::malloc()` to allocate memory in C heap for immutable nmethod's data. Call `vm_exit_out_of_memory()` if allocation failed.
> 
> Shuffle fields order and change some fields size from 4 to 2 bytes to avoid nmethod's header size increase.
> 
> Tested tier1-5, stress,xcomp
> 
> Our performance testing does not show difference.
> 
> Example of updated `-XX:+PrintNMethodStatistics` output is in JBS comment.

This pull request has now been integrated.

Changeset: bdcc2400
Author:    Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bdcc2400db63e604d76f9b5bd3c876271743f69f
Stats:     311 lines in 5 files changed: 163 ins; 42 del; 106 mod

8331087: Move immutable nmethod data from CodeCache

Reviewed-by: thartmann, dlong, dnsimon

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

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

From kbarrett at openjdk.org  Mon Apr 29 22:57:04 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 29 Apr 2024 22:57:04 GMT
Subject: RFR: 8330694: Rename 'HeapRegion' to 'G1HeapRegion' [v4]
In-Reply-To: <xZ9uTLfJfGyvsoRO1Y32NoV-NuGpJ-3C3J0voQCcNEA=.65cada0e-b01f-4789-b82d-b18b1415d942@github.com>
References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
 <tKoc_1Z7ZAN6YuR_BpkrbOMi54UoDk0WYeHHK5aE3XE=.0ca685db-af09-4885-89ee-e35b0e9cf2b8@github.com>
 <xZ9uTLfJfGyvsoRO1Y32NoV-NuGpJ-3C3J0voQCcNEA=.65cada0e-b01f-4789-b82d-b18b1415d942@github.com>
Message-ID: <MdjuKI_cmnO4JudzDFqZkIdKHE4bUxR5ZWm4uj_rUzY=.b6070aad-ed0e-4a04-8f2d-93e179c639a5@github.com>

On Mon, 29 Apr 2024 08:14:03 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> mach5 higher tier SA tests are fine. What are your plans for the remaining SA renames (would highly recommend to add) and the G1HeapRegion related helper classes?

I suggest the related helper classes be done in further followups, not make this change even larger.

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

PR Comment: https://git.openjdk.org/jdk/pull/18871#issuecomment-2083822517

From sspitsyn at openjdk.org  Tue Apr 30 01:38:05 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 30 Apr 2024 01:38:05 GMT
Subject: RFR: 8330969: scalability issue with loaded JVMTI agent [v2]
In-Reply-To: <f-SKLHRYrAIwMR9tGth-_BsschetH2jMiXS0kx_ORD4=.3f61ca66-61d4-4f8d-9233-b01d852ae846@github.com>
References: <FvcDTtfEpTjQmcSjEPSmKjpUloHElpk6uUPc7VPjc2U=.01a08d3f-5906-4429-9472-61218603f613@github.com>
 <XkAPnKpNsajt7wuCSz_05DMueqXM2taByHw0_mS1vXo=.9d0bc5f7-f32d-4778-b334-4adc51e4deea@github.com>
 <f-SKLHRYrAIwMR9tGth-_BsschetH2jMiXS0kx_ORD4=.3f61ca66-61d4-4f8d-9233-b01d852ae846@github.com>
Message-ID: <0o3TzcU6vozIPUYiF7iG9ZZ2t1HFNrJMsn2eivviKJU=.be506b1b-bec9-45ab-bd19-1101be512be8@github.com>

On Fri, 26 Apr 2024 19:38:40 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: fixed minor issues: renamed function, corrected comment, removed typo in assert
>
> src/hotspot/share/prims/jvmtiThreadState.cpp line 433:
> 
>> 431:   // Avoid using MonitorLocker on performance critical path, use
>> 432:   // two-level synchronization with lock-free operations on counters.
>> 433:   assert(!thread->VTMS_transition_mark(), "sanity check");
> 
> The "counters" comment needs to be updated.

Nice catch, thanks. Fixed now.

> src/hotspot/share/prims/jvmtiThreadState.cpp line 456:
> 
>> 454:     // Slow path: undo unsuccessful optimistic counter incrementation.
>> 455:     // It can cause an extra waiting cycle for VTMS transition disablers.
>> 456:     thread->set_VTMS_transition_mark(false);
> 
> The "optimistic counter incrementation" comment needs updating.

Nice catch, thanks. Fixed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18937#discussion_r1584018624
PR Review Comment: https://git.openjdk.org/jdk/pull/18937#discussion_r1584018405

From sspitsyn at openjdk.org  Tue Apr 30 01:52:09 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 30 Apr 2024 01:52:09 GMT
Subject: RFR: 8330969: scalability issue with loaded JVMTI agent [v2]
In-Reply-To: <f-SKLHRYrAIwMR9tGth-_BsschetH2jMiXS0kx_ORD4=.3f61ca66-61d4-4f8d-9233-b01d852ae846@github.com>
References: <FvcDTtfEpTjQmcSjEPSmKjpUloHElpk6uUPc7VPjc2U=.01a08d3f-5906-4429-9472-61218603f613@github.com>
 <XkAPnKpNsajt7wuCSz_05DMueqXM2taByHw0_mS1vXo=.9d0bc5f7-f32d-4778-b334-4adc51e4deea@github.com>
 <f-SKLHRYrAIwMR9tGth-_BsschetH2jMiXS0kx_ORD4=.3f61ca66-61d4-4f8d-9233-b01d852ae846@github.com>
Message-ID: <OySW23RnwQQOK1Dl721B1uHiculZ6Qx-l0sNm5gRl7E=.7ffd070e-1f0d-4f2a-bbf3-5f7dcbe520b0@github.com>

On Fri, 26 Apr 2024 19:34:55 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: fixed minor issues: renamed function, corrected comment, removed typo in assert
>
> src/hotspot/share/prims/jvmtiThreadState.cpp line 366:
> 
>> 364:           attempts--;
>> 365:         }
>> 366:         DEBUG_ONLY(if (attempts == 0) break;)
> 
> Previously `_VTMS_transition_count` considered all threads at the same time. Now you are iterating through the threads and looking at a flag in each one. Is it guaranteed that once the `_VTMS_transition_mark` flag has been verified not to be set in a thread it won't get set while still iterating in the threads loop?

Thank you for the comment. It is thinking in a right direction.
Each `JavaThread` set the `VTM_transition_mark` only once and then checks for disable counters:
 - `_VTMS_transition_disable_for_all_count`
 - `java_lang_Thread::VTMS_transition_disable_count(vth())`
 
If any of the disable counters is not zero then each `JavaThread` clears the optimistically set mark and continues under protection of the `JvmtiVTMSTransition_lock`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18937#discussion_r1584025182

From sspitsyn at openjdk.org  Tue Apr 30 01:56:13 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 30 Apr 2024 01:56:13 GMT
Subject: RFR: 8330969: scalability issue with loaded JVMTI agent [v3]
In-Reply-To: <FvcDTtfEpTjQmcSjEPSmKjpUloHElpk6uUPc7VPjc2U=.01a08d3f-5906-4429-9472-61218603f613@github.com>
References: <FvcDTtfEpTjQmcSjEPSmKjpUloHElpk6uUPc7VPjc2U=.01a08d3f-5906-4429-9472-61218603f613@github.com>
Message-ID: <dctd9wCAuKFLps45I5N1aJ3Hd-ydN06DUV29Cyk40bE=.5ff5d279-61df-40d0-af92-7e315ded5a34@github.com>

> This is a fix of the following JVMTI scalability issue. A closed benchmark with millions of virtual threads shows 3X-4X overhead when a JVMTI agent has been loaded. For instance, this is observable when an app is executed under control of the Oracle Studio `collect` utility.
> For performance analysis, experiments and numbers, please, see the comment below this description.
> 
> The fix is to replace the global counter `_VTMS_transition_count` with the mark bit `_VTMS_transition_mark` in each `JavaThread`'.
> 
> Testing:
>  - Tested with mach5 tiers 1-6

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

  review: correct comments related to VTMS transition counters

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18937/files
  - new: https://git.openjdk.org/jdk/pull/18937/files/03bcfecb..173840b5

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

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

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

From sspitsyn at openjdk.org  Tue Apr 30 02:08:03 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 30 Apr 2024 02:08:03 GMT
Subject: RFR: 8330852: All callers of
 JvmtiEnvBase::get_threadOop_and_JavaThread should pass current thread
 explicitly
In-Reply-To: <HHDWPZJogKzfDNvS2dJ2xxUKh9w0-qYtM5tiSUjCBdk=.342df145-c872-455d-b65e-f5c8b729e781@github.com>
References: <HHDWPZJogKzfDNvS2dJ2xxUKh9w0-qYtM5tiSUjCBdk=.342df145-c872-455d-b65e-f5c8b729e781@github.com>
Message-ID: <OHzxCEIG9lnSKskLMuQ75FSVEINtqmhbT3pB4NQk-h0=.48456455-27a8-4736-9d80-9af2feaddbff@github.com>

On Fri, 26 Apr 2024 22:59:43 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Some cleanup related to JvmtiEnvBase::get_threadOop_and_JavaThread method
> 
> Testing: tier1-6

This looks good in general. Thank you for taking care about it. The Runtime team suggested to use the name `current` for the current thread. The plan is to unify the JVMTI code as well. So, I'd suggest to rename all occurrences of the `current_thread` that you touched to the `current`. It will be a good step in a right direction. I'm already doing it for some time.

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

PR Review: https://git.openjdk.org/jdk/pull/18986#pullrequestreview-2030037342

From sspitsyn at openjdk.org  Tue Apr 30 02:08:04 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 30 Apr 2024 02:08:04 GMT
Subject: RFR: 8330852: All callers of
 JvmtiEnvBase::get_threadOop_and_JavaThread should pass current thread
 explicitly
In-Reply-To: <SREtir9aP4YOBYbn6pXv-d2Mt9JA20_g9bL0WeTKMys=.7f9b8413-0689-4820-a2f0-871692fd51ee@github.com>
References: <HHDWPZJogKzfDNvS2dJ2xxUKh9w0-qYtM5tiSUjCBdk=.342df145-c872-455d-b65e-f5c8b729e781@github.com>
 <zJDP5yOYfBRaNXFcNaxW7grk5cA_ry_ZTEnE3a2YNyg=.64f9ace6-db9e-42b5-af81-ed7acac2269c@github.com>
 <SREtir9aP4YOBYbn6pXv-d2Mt9JA20_g9bL0WeTKMys=.7f9b8413-0689-4820-a2f0-871692fd51ee@github.com>
Message-ID: <U14JnG2n1JtunonMxDYtGQq-_PpZf-RfosBEbLteP1E=.471d3d9a-9bb9-4fbe-8366-a54b32af5846@github.com>

On Sat, 27 Apr 2024 00:01:16 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1976:
>> 
>>> 1974:   oop thread_obj = nullptr;
>>> 1975: 
>>> 1976:   jvmtiError err = JvmtiEnvBase::get_threadOop_and_JavaThread(tlh.list(), target, current, &java_thread, &thread_obj);
>> 
>> I think a good cleanup would be to also replace `current` with `current_thread`, although I'm not sure how common each are. I see 3 `current` references in this webrev.
>
> Looks like in JVMTI `current_thread` is more common (and `current` is usually used in runtime :)

The plan is to unify this with the approach used by the Runtime team.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18986#discussion_r1584032225

From sspitsyn at openjdk.org  Tue Apr 30 02:29:05 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 30 Apr 2024 02:29:05 GMT
Subject: RFR: 8322043: HeapDumper should use parallel dump by default [v5]
In-Reply-To: <mxfsfJYeBPTzpL8ttJwLDSb_unfUg-ta444F_HcF7LI=.d2176032-6af9-4249-99ae-3c1ed18188d9@github.com>
References: <m5p4qFndNtWAo_wwbdHKSJqG2XIcxwn_3tcJAYXAwgA=.dd4128e5-9688-45da-919e-683f4f6c6a10@github.com>
 <mxfsfJYeBPTzpL8ttJwLDSb_unfUg-ta444F_HcF7LI=.d2176032-6af9-4249-99ae-3c1ed18188d9@github.com>
Message-ID: <j0YjmTKF0wNNgqKxcGbhlDFPFR-HSB_E0yADVwnjepE=.6eab2e27-bfc8-4a8c-9efe-b327371d0bb5@github.com>

On Wed, 17 Apr 2024 20:42:54 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix makes VM heap dumping parallel by default.
>> `jcmd GC.heap_dump` and `jmap -dump` had parallel dumping by default, the fix affects `HotSpotDiagnosticMXBean.dumpHeap()`, `-XX:+HeapDumpBeforeFullGC`, `-XX:+HeapDumpAfterFullGC` and `-XX:+HeapDumpOnOutOfMemoryError`.
>> 
>> Testing:
>>   - manually tested different heap dump scenarios with `-Xlog:heapdump`;
>>   - tier1,tier2,hs-tier5-svc;
>>   - all reg.tests that use heap dump.
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed unneeded cast

This looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18748#pullrequestreview-2030062605

From dholmes at openjdk.org  Tue Apr 30 04:27:06 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 30 Apr 2024 04:27:06 GMT
Subject: RFR: 8322043: HeapDumper should use parallel dump by default [v5]
In-Reply-To: <mxfsfJYeBPTzpL8ttJwLDSb_unfUg-ta444F_HcF7LI=.d2176032-6af9-4249-99ae-3c1ed18188d9@github.com>
References: <m5p4qFndNtWAo_wwbdHKSJqG2XIcxwn_3tcJAYXAwgA=.dd4128e5-9688-45da-919e-683f4f6c6a10@github.com>
 <mxfsfJYeBPTzpL8ttJwLDSb_unfUg-ta444F_HcF7LI=.d2176032-6af9-4249-99ae-3c1ed18188d9@github.com>
Message-ID: <K4Rj2ruuB4GZKLOf-2bU6PniBEJmYJTpkyQFz8XxiWU=.3d50399b-1ff3-46e7-a9d1-6c6811d808bd@github.com>

On Wed, 17 Apr 2024 20:42:54 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix makes VM heap dumping parallel by default.
>> `jcmd GC.heap_dump` and `jmap -dump` had parallel dumping by default, the fix affects `HotSpotDiagnosticMXBean.dumpHeap()`, `-XX:+HeapDumpBeforeFullGC`, `-XX:+HeapDumpAfterFullGC` and `-XX:+HeapDumpOnOutOfMemoryError`.
>> 
>> Testing:
>>   - manually tested different heap dump scenarios with `-Xlog:heapdump`;
>>   - tier1,tier2,hs-tier5-svc;
>>   - all reg.tests that use heap dump.
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed unneeded cast

One nit, otherwise looks good. Thanks

src/hotspot/share/services/diagnosticCommand.cpp line 523:

> 521:   // and makes it easier to browse.
> 522:   HeapDumper dumper(!_all.value() /* request GC if _all is false*/);
> 523:   dumper.dump(_filename.value(), output(), (int)level, _overwrite.value(), (uint)parallel);

I'm not sure what the prevalent style is for cast operators, but I don't see any point doing this in this PR when the file is otherwise untouched. Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18748#pullrequestreview-2030177251
PR Review Comment: https://git.openjdk.org/jdk/pull/18748#discussion_r1584110521

From sspitsyn at openjdk.org  Tue Apr 30 05:28:03 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 30 Apr 2024 05:28:03 GMT
Subject: RFR: 8320215: HeapDumper can use DumpWriter buffer during merge
In-Reply-To: <tImZFe13oYNkG6sz8Wk2RpUawTiym48oxvAS3pXFHWo=.490751ea-331f-4399-b9ee-98a7c179ee30@github.com>
References: <tImZFe13oYNkG6sz8Wk2RpUawTiym48oxvAS3pXFHWo=.490751ea-331f-4399-b9ee-98a7c179ee30@github.com>
Message-ID: <34SEuGvhZ_HuwQuOOUZuHnD2dazgUV1RIyxYdlU3d4I=.3d0d6d2d-85e1-4632-8fa3-af475f4723c9@github.com>

On Fri, 19 Apr 2024 00:10:12 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates HeapMerger to use writer buffer (no need to copy memory, also writer buffer is 1MB instead of 4KB).
> Additionally fixed small issue in FileWriter (looks like `ssize_t` instead of `size_t` is a typo, the argument should be unsigned)
> 
> Testing: all HeapDump-related tests on Oracle supported platforms

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18850#pullrequestreview-2030232272

From tschatzl at openjdk.org  Tue Apr 30 07:14:10 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 30 Apr 2024 07:14:10 GMT
Subject: RFR: 8330694: Rename 'HeapRegion' to 'G1HeapRegion' [v4]
In-Reply-To: <MdjuKI_cmnO4JudzDFqZkIdKHE4bUxR5ZWm4uj_rUzY=.b6070aad-ed0e-4a04-8f2d-93e179c639a5@github.com>
References: <3IdWn9VGEERd8v9RcH2E_LzjVo0L8nMfi5jGWmhgVuM=.6b5b3be4-bfbd-4376-9580-48d78d75665c@github.com>
 <tKoc_1Z7ZAN6YuR_BpkrbOMi54UoDk0WYeHHK5aE3XE=.0ca685db-af09-4885-89ee-e35b0e9cf2b8@github.com>
 <xZ9uTLfJfGyvsoRO1Y32NoV-NuGpJ-3C3J0voQCcNEA=.65cada0e-b01f-4789-b82d-b18b1415d942@github.com>
 <MdjuKI_cmnO4JudzDFqZkIdKHE4bUxR5ZWm4uj_rUzY=.b6070aad-ed0e-4a04-8f2d-93e179c639a5@github.com>
Message-ID: <vWPggYRQSMS7LUo3haCJseSdyYLmaNA5v_jqlKCt5k0=.a4f85365-36f4-4698-8063-56eec6431b55@github.com>

On Mon, 29 Apr 2024 22:54:18 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> > mach5 higher tier SA tests are fine. What are your plans for the remaining SA renames (would highly recommend to add) and the G1HeapRegion related helper classes?
> 
> I suggest the related helper classes be done in further followups, not make this change even larger.

Fine with me, will file an issue about the helper classes.

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

PR Comment: https://git.openjdk.org/jdk/pull/18871#issuecomment-2084539234

From jpai at openjdk.org  Tue Apr 30 09:59:25 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 30 Apr 2024 09:59:25 GMT
Subject: RFR: 8308033: The jcmd thread dump related tests should test virtual
 threads
Message-ID: <p4P_QOv2Jo-S6cimVwoeDCdMuDyqNDembdXsHdX74VI=.15aa4261-0b53-4f02-86bf-d92566914b66@github.com>

Can I please get a review of these test-only changes which proposes to remove the `test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java` and `test/jdk/sun/tools/jstack/BasicJStackTest.java` tests from `ProblemList-Virtual.txt`?

When jtreg was enhanced to allow running the tests from within a virtual (main) thread, some tests were problem listed since they either were failing at that time or the test code would require additional work to make it work when the current thread is a virtual thread. The `test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java` and `test/jdk/sun/tools/jstack/BasicJStackTest.java` are 2 such threads which require special handling when the current thread is a virtual thread.

`test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java` has been updated to use a different command to dump stacktraces when the test runs in a virtual thread. I went back and looked at the original issue for which this test was introduced and based on that, using a different command to dump the stacktraces shouldn't impact what the test was originally intended to test.

`test/jdk/sun/tools/jstack/BasicJStackTest.java` has been updated to be skipped when the current thread is the virtual thread. This is because the test exercises the `jstack` tool which doesn't print stacktraces of virtual threads and thus the test isn't applicable for virtual threads.

I've run these tests with this change, both with platform threads and virtual threads in our CI and the tests complete without failures.

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

Commit messages:
 - 8308033: The jcmd thread dump related tests should test virtual threads

Changes: https://git.openjdk.org/jdk/pull/19016/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19016&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308033
  Stats: 51 lines in 3 files changed: 42 ins; 3 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/19016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19016/head:pull/19016

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

From jpai at openjdk.org  Tue Apr 30 11:31:03 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 30 Apr 2024 11:31:03 GMT
Subject: RFR: 8308033: The jcmd thread dump related tests should test
 virtual threads
In-Reply-To: <p4P_QOv2Jo-S6cimVwoeDCdMuDyqNDembdXsHdX74VI=.15aa4261-0b53-4f02-86bf-d92566914b66@github.com>
References: <p4P_QOv2Jo-S6cimVwoeDCdMuDyqNDembdXsHdX74VI=.15aa4261-0b53-4f02-86bf-d92566914b66@github.com>
Message-ID: <EhiwcygtwMw-PzjG5L06MGvvC7WbXXanhazVR95E_50=.95cda89f-6e2c-4717-b789-f08431904235@github.com>

On Tue, 30 Apr 2024 09:54:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of these test-only changes which proposes to remove the `test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java` and `test/jdk/sun/tools/jstack/BasicJStackTest.java` tests from `ProblemList-Virtual.txt`?
> 
> When jtreg was enhanced to allow running the tests from within a virtual (main) thread, some tests were problem listed since they either were failing at that time or the test code would require additional work to make it work when the current thread is a virtual thread. The `test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java` and `test/jdk/sun/tools/jstack/BasicJStackTest.java` are 2 such threads which require special handling when the current thread is a virtual thread.
> 
> `test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java` has been updated to use a different command to dump stacktraces when the test runs in a virtual thread. I went back and looked at the original issue for which this test was introduced and based on that, using a different command to dump the stacktraces shouldn't impact what the test was originally intended to test.
> 
> `test/jdk/sun/tools/jstack/BasicJStackTest.java` has been updated to be skipped when the current thread is the virtual thread. This is because the test exercises the `jstack` tool which doesn't print stacktraces of virtual threads and thus the test isn't applicable for virtual threads.
> 
> I've run these tests with this change, both with platform threads and virtual threads in our CI and the tests complete without failures.

> 8308033 is used in problem lists: [test/hotspot/jtreg/ProblemList-Virtual.txt]

It looks like the same bug id is being used in multiple different areas for different tests. I'll put this PR on draft for now, till I review if the following tests that are linked against this bug id can be removed from the problem listing or fixed too:


serviceability/dcmd/thread/PrintConcurrentLocksTest.java 8308033 generic-all
serviceability/dcmd/thread/PrintTest.java 8308033 generic-all
serviceability/dcmd/thread/ThreadDumpToFileTest.java 8308033 generic-all
serviceability/tmtools/jstack/DaemonThreadTest.java 8308033 generic-all

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

PR Comment: https://git.openjdk.org/jdk/pull/19016#issuecomment-2085044069

From jpai at openjdk.org  Tue Apr 30 12:08:21 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 30 Apr 2024 12:08:21 GMT
Subject: RFR: 8308033: The jcmd thread dump related tests should test
 virtual threads [v2]
In-Reply-To: <p4P_QOv2Jo-S6cimVwoeDCdMuDyqNDembdXsHdX74VI=.15aa4261-0b53-4f02-86bf-d92566914b66@github.com>
References: <p4P_QOv2Jo-S6cimVwoeDCdMuDyqNDembdXsHdX74VI=.15aa4261-0b53-4f02-86bf-d92566914b66@github.com>
Message-ID: <CYNyMAFC5P60jIloEzUvfBJ2R9SygWkIHIKiMLN5N-0=.df71c1be-4235-4f1f-b352-4f7dbf1830d3@github.com>

> Can I please get a review of these test-only changes which proposes to remove the `test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java` and `test/jdk/sun/tools/jstack/BasicJStackTest.java` tests from `ProblemList-Virtual.txt`?
> 
> When jtreg was enhanced to allow running the tests from within a virtual (main) thread, some tests were problem listed since they either were failing at that time or the test code would require additional work to make it work when the current thread is a virtual thread. The `test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java` and `test/jdk/sun/tools/jstack/BasicJStackTest.java` are 2 such threads which require special handling when the current thread is a virtual thread.
> 
> `test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java` has been updated to use a different command to dump stacktraces when the test runs in a virtual thread. I went back and looked at the original issue for which this test was introduced and based on that, using a different command to dump the stacktraces shouldn't impact what the test was originally intended to test.
> 
> `test/jdk/sun/tools/jstack/BasicJStackTest.java` has been updated to be skipped when the current thread is the virtual thread. This is because the test exercises the `jstack` tool which doesn't print stacktraces of virtual threads and thus the test isn't applicable for virtual threads.
> 
> I've run these tests with this change, both with platform threads and virtual threads in our CI and the tests complete without failures.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  address additional problem listed tests in hotspot/jtreg/serviceability

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19016/files
  - new: https://git.openjdk.org/jdk/pull/19016/files/201be489..6193cfbb

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

  Stats: 20 lines in 3 files changed: 12 ins; 4 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/19016.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19016/head:pull/19016

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

From jpai at openjdk.org  Tue Apr 30 12:14:05 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 30 Apr 2024 12:14:05 GMT
Subject: RFR: 8308033: The jcmd thread dump related tests should test
 virtual threads [v2]
In-Reply-To: <CYNyMAFC5P60jIloEzUvfBJ2R9SygWkIHIKiMLN5N-0=.df71c1be-4235-4f1f-b352-4f7dbf1830d3@github.com>
References: <p4P_QOv2Jo-S6cimVwoeDCdMuDyqNDembdXsHdX74VI=.15aa4261-0b53-4f02-86bf-d92566914b66@github.com>
 <CYNyMAFC5P60jIloEzUvfBJ2R9SygWkIHIKiMLN5N-0=.df71c1be-4235-4f1f-b352-4f7dbf1830d3@github.com>
Message-ID: <7sc08xuI5H3EpIhuUKhZO4mycpBkzQjeELpS2boeaeY=.a7db8bb0-7284-4cd1-8127-1e3c47a19be4@github.com>

On Tue, 30 Apr 2024 12:08:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of these test-only changes which proposes to remove the `test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java` and `test/jdk/sun/tools/jstack/BasicJStackTest.java` tests from `ProblemList-Virtual.txt`?
>> 
>> When jtreg was enhanced to allow running the tests from within a virtual (main) thread, some tests were problem listed since they either were failing at that time or the test code would require additional work to make it work when the current thread is a virtual thread. The `test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java` and `test/jdk/sun/tools/jstack/BasicJStackTest.java` are 2 such threads which require special handling when the current thread is a virtual thread.
>> 
>> `test/jdk/sun/tools/jcmd/JcmdOutputEncodingTest.java` has been updated to use a different command to dump stacktraces when the test runs in a virtual thread. I went back and looked at the original issue for which this test was introduced and based on that, using a different command to dump the stacktraces shouldn't impact what the test was originally intended to test.
>> 
>> `test/jdk/sun/tools/jstack/BasicJStackTest.java` has been updated to be skipped when the current thread is the virtual thread. This is because the test exercises the `jstack` tool which doesn't print stacktraces of virtual threads and thus the test isn't applicable for virtual threads.
>> 
>> I've run these tests with this change, both with platform threads and virtual threads in our CI and the tests complete without failures.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address additional problem listed tests in hotspot/jtreg/serviceability

I've opened this for review again. The additional changes were straightforward. The `test/hotspot/jtreg/serviceability/dcmd/thread/` tests which were problem listed were testing `Thread.print` command against the current thread. Those have now been updated to skip the tests when the current thread is a virtual thread, since `Thread.print` doesn't generate thread dumps for virtual threads.

The `test/hotspot/jtreg/serviceability/tmtools/jstack/DaemonThreadTest.java` has been updated to explicitly mark a (platform) thread launched from within the test as non-daemon to verify that the output of `jstack` correctly captures that state.

With these changes all these tests pass, both when jtreg uses platform thread and  virtual thread to launch the tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/19016#issuecomment-2085163934

From never at openjdk.org  Tue Apr 30 17:36:39 2024
From: never at openjdk.org (Tom Rodriguez)
Date: Tue, 30 Apr 2024 17:36:39 GMT
Subject: RFR: 8318682: SA decoding of scalar replaced objects is broken
 [v7]
In-Reply-To: <R64I76cjq_B8227oAI3C_B62NQSa3-HVn13a6Fj0alo=.28a782c9-d03c-4126-9aab-6e6134b0dbe1@github.com>
References: <R64I76cjq_B8227oAI3C_B62NQSa3-HVn13a6Fj0alo=.28a782c9-d03c-4126-9aab-6e6134b0dbe1@github.com>
Message-ID: <DqxPsqkdPYF2zhpjLpX08lqJPOXNDFE3v_6VRMirYqo=.5498d4ad-135b-46fb-a529-f62605f09295@github.com>

> The changes for JDK-8287061 didn't update the SA decoding logic and there are other places where the decoding has gotten out of sync with HotSpot.  Some of them can't be tested because they are part of JVMCI but I've added a directed test for the JDK-8287061 code and a more brute force test that tries to decode everything.

Tom Rodriguez 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 10 additional commits since the last revision:

 - Merge branch 'master' into tkr-hsdb-assert
 - Merge branch 'master' into tkr-hsdb-assert
 - Review comments
 - Remove testdebuginfodecode command
 - Update src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/NMethod.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Update src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Pass the proper options to the lingered app
 - Fix problem list and correct jtreg arguments
 - Add missing files
 - 8318682: SA decoding of scalar replaced objects is broken

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17407/files
  - new: https://git.openjdk.org/jdk/pull/17407/files/f25c92ef..3cafefc6

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

  Stats: 663952 lines in 9058 files changed: 132224 ins; 168721 del; 363007 mod
  Patch: https://git.openjdk.org/jdk/pull/17407.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17407/head:pull/17407

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

From never at openjdk.org  Tue Apr 30 17:36:39 2024
From: never at openjdk.org (Tom Rodriguez)
Date: Tue, 30 Apr 2024 17:36:39 GMT
Subject: RFR: 8318682: SA decoding of scalar replaced objects is broken
 [v6]
In-Reply-To: <3vUQFrFjSw6SBZMlDqrUNW0-e37Ocj3hoGPU5qXE-EQ=.32395005-fc6c-486a-b384-78bbeac409b2@github.com>
References: <R64I76cjq_B8227oAI3C_B62NQSa3-HVn13a6Fj0alo=.28a782c9-d03c-4126-9aab-6e6134b0dbe1@github.com>
 <3vUQFrFjSw6SBZMlDqrUNW0-e37Ocj3hoGPU5qXE-EQ=.32395005-fc6c-486a-b384-78bbeac409b2@github.com>
Message-ID: <ZyoaqUmCmtNr6fygTFF54qtf8B5Oopr3H4gGdjP-abw=.d26fcb63-52b0-4657-9a7e-f8f5c6d277fc@github.com>

On Wed, 17 Jan 2024 19:52:32 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> The changes for JDK-8287061 didn't update the SA decoding logic and there are other places where the decoding has gotten out of sync with HotSpot.  Some of them can't be tested because they are part of JVMCI but I've added a directed test for the JDK-8287061 code and a more brute force test that tries to decode everything.
>
> Tom Rodriguez has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

I merged with master and reran all tests which were clean

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

PR Comment: https://git.openjdk.org/jdk/pull/17407#issuecomment-2086158736

From never at openjdk.org  Tue Apr 30 17:36:41 2024
From: never at openjdk.org (Tom Rodriguez)
Date: Tue, 30 Apr 2024 17:36:41 GMT
Subject: Integrated: 8318682: SA decoding of scalar replaced objects is broken
In-Reply-To: <R64I76cjq_B8227oAI3C_B62NQSa3-HVn13a6Fj0alo=.28a782c9-d03c-4126-9aab-6e6134b0dbe1@github.com>
References: <R64I76cjq_B8227oAI3C_B62NQSa3-HVn13a6Fj0alo=.28a782c9-d03c-4126-9aab-6e6134b0dbe1@github.com>
Message-ID: <6TTS47-QRjcR0xDZKCtK_hueTYX3DRIW5wu8ikwYKe4=.8eb5b09a-921a-472a-8786-b343a6487678@github.com>

On Fri, 12 Jan 2024 21:26:36 GMT, Tom Rodriguez <never at openjdk.org> wrote:

> The changes for JDK-8287061 didn't update the SA decoding logic and there are other places where the decoding has gotten out of sync with HotSpot.  Some of them can't be tested because they are part of JVMCI but I've added a directed test for the JDK-8287061 code and a more brute force test that tries to decode everything.

This pull request has now been integrated.

Changeset: b96b38c2
Author:    Tom Rodriguez <never at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b96b38c2c9a310d5fe49b2eda3e113a71223c7d1
Stats:     427 lines in 13 files changed: 413 ins; 4 del; 10 mod

8318682: SA decoding of scalar replaced objects is broken

Reviewed-by: cjplummer, cslucas

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

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

From amenkov at openjdk.org  Tue Apr 30 18:54:09 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 30 Apr 2024 18:54:09 GMT
Subject: RFR: 8322043: HeapDumper should use parallel dump by default [v6]
In-Reply-To: <m5p4qFndNtWAo_wwbdHKSJqG2XIcxwn_3tcJAYXAwgA=.dd4128e5-9688-45da-919e-683f4f6c6a10@github.com>
References: <m5p4qFndNtWAo_wwbdHKSJqG2XIcxwn_3tcJAYXAwgA=.dd4128e5-9688-45da-919e-683f4f6c6a10@github.com>
Message-ID: <oKw_lwvggGR1lO90lIqvwzDVsV0Qqp0heQgm-TGdFjU=.a27a162d-b28f-4b22-9a3d-3d185666ddac@github.com>

> The fix makes VM heap dumping parallel by default.
> `jcmd GC.heap_dump` and `jmap -dump` had parallel dumping by default, the fix affects `HotSpotDiagnosticMXBean.dumpHeap()`, `-XX:+HeapDumpBeforeFullGC`, `-XX:+HeapDumpAfterFullGC` and `-XX:+HeapDumpOnOutOfMemoryError`.
> 
> Testing:
>   - manually tested different heap dump scenarios with `-Xlog:heapdump`;
>   - tier1,tier2,hs-tier5-svc;
>   - all reg.tests that use heap dump.

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  removed space-only change in diagnosticCommand.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18748/files
  - new: https://git.openjdk.org/jdk/pull/18748/files/641bedc5..eb38705d

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

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

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

From amenkov at openjdk.org  Tue Apr 30 19:03:53 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 30 Apr 2024 19:03:53 GMT
Subject: RFR: 8330969: scalability issue with loaded JVMTI agent [v3]
In-Reply-To: <dctd9wCAuKFLps45I5N1aJ3Hd-ydN06DUV29Cyk40bE=.5ff5d279-61df-40d0-af92-7e315ded5a34@github.com>
References: <FvcDTtfEpTjQmcSjEPSmKjpUloHElpk6uUPc7VPjc2U=.01a08d3f-5906-4429-9472-61218603f613@github.com>
 <dctd9wCAuKFLps45I5N1aJ3Hd-ydN06DUV29Cyk40bE=.5ff5d279-61df-40d0-af92-7e315ded5a34@github.com>
Message-ID: <YaVZJVWj9670j3ZawD3bTowW5abq4etajX_n2STZQmY=.7cb708c0-0278-4e7f-a04f-71311876e9c9@github.com>

On Tue, 30 Apr 2024 01:56:13 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is a fix of the following JVMTI scalability issue. A closed benchmark with millions of virtual threads shows 3X-4X overhead when a JVMTI agent has been loaded. For instance, this is observable when an app is executed under control of the Oracle Studio `collect` utility.
>> For performance analysis, experiments and numbers, please, see the comment below this description.
>> 
>> The fix is to replace the global counter `_VTMS_transition_count` with the mark bit `_VTMS_transition_mark` in each `JavaThread`'.
>> 
>> Testing:
>>  - Tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: correct comments related to VTMS transition counters

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18937#pullrequestreview-2032255537

From cjplummer at openjdk.org  Tue Apr 30 19:34:53 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 30 Apr 2024 19:34:53 GMT
Subject: RFR: 8330969: scalability issue with loaded JVMTI agent [v3]
In-Reply-To: <dctd9wCAuKFLps45I5N1aJ3Hd-ydN06DUV29Cyk40bE=.5ff5d279-61df-40d0-af92-7e315ded5a34@github.com>
References: <FvcDTtfEpTjQmcSjEPSmKjpUloHElpk6uUPc7VPjc2U=.01a08d3f-5906-4429-9472-61218603f613@github.com>
 <dctd9wCAuKFLps45I5N1aJ3Hd-ydN06DUV29Cyk40bE=.5ff5d279-61df-40d0-af92-7e315ded5a34@github.com>
Message-ID: <K5-b9oomLlDxPgpSWUyiLaGl3vVVKDxY7oFOgJoc_dE=.a319743b-656f-470b-a9a7-83918bd23a6a@github.com>

On Tue, 30 Apr 2024 01:56:13 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is a fix of the following JVMTI scalability issue. A closed benchmark with millions of virtual threads shows 3X-4X overhead when a JVMTI agent has been loaded. For instance, this is observable when an app is executed under control of the Oracle Studio `collect` utility.
>> For performance analysis, experiments and numbers, please, see the comment below this description.
>> 
>> The fix is to replace the global counter `_VTMS_transition_count` with the mark bit `_VTMS_transition_mark` in each `JavaThread`'.
>> 
>> Testing:
>>  - Tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: correct comments related to VTMS transition counters

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18937#pullrequestreview-2032369700

From amenkov at openjdk.org  Tue Apr 30 23:25:04 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 30 Apr 2024 23:25:04 GMT
Subject: RFR: 8330852: All callers of
 JvmtiEnvBase::get_threadOop_and_JavaThread should pass current thread
 explicitly [v2]
In-Reply-To: <HHDWPZJogKzfDNvS2dJ2xxUKh9w0-qYtM5tiSUjCBdk=.342df145-c872-455d-b65e-f5c8b729e781@github.com>
References: <HHDWPZJogKzfDNvS2dJ2xxUKh9w0-qYtM5tiSUjCBdk=.342df145-c872-455d-b65e-f5c8b729e781@github.com>
Message-ID: <vh5hb0SRabn0Rv35hmeZV1uCfVXfRrGe5Sw4p1896MM=.8c77242a-3f61-450d-9843-1d2b6116c7b1@github.com>

> Some cleanup related to JvmtiEnvBase::get_threadOop_and_JavaThread method
> 
> Testing: tier1-6

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  renamed current_thread to current

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18986/files
  - new: https://git.openjdk.org/jdk/pull/18986/files/f472f669..d5d614bc

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

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

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

From amenkov at openjdk.org  Tue Apr 30 23:48:02 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 30 Apr 2024 23:48:02 GMT
Subject: RFR: 8330852: All callers of
 JvmtiEnvBase::get_threadOop_and_JavaThread should pass current thread
 explicitly [v3]
In-Reply-To: <HHDWPZJogKzfDNvS2dJ2xxUKh9w0-qYtM5tiSUjCBdk=.342df145-c872-455d-b65e-f5c8b729e781@github.com>
References: <HHDWPZJogKzfDNvS2dJ2xxUKh9w0-qYtM5tiSUjCBdk=.342df145-c872-455d-b65e-f5c8b729e781@github.com>
Message-ID: <lNh5HCmBBIGyDubznqoEP5cWGxeRpEKQFdY5JbwgJ2c=.8f2a07e4-d73a-49ea-a8a9-f49f0a8567c5@github.com>

> Some cleanup related to JvmtiEnvBase::get_threadOop_and_JavaThread method
> 
> Testing: tier1-6

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  renamed current_thread tp current

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18986/files
  - new: https://git.openjdk.org/jdk/pull/18986/files/d5d614bc..46026322

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

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

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